Health Ontology Mapper Specifications Document

Revision 1.00

Academic Research Systems

Office of Academic & Administrative Information Systems

For comments or feedback on this document, call (415) 514-4100, option 2

August, 2009

Table of Contents

1 Introduction

1.1 Purpose

1.2 Intended Audience

1.3 Project Scope

1.4 References

2 Overall Description

2.1 Product Perspective

2.2 Product Features

2.3 User Classes and Characteristics

2.4 Operating Environment

2.5 Design and Implementation Constraints

2.6 User Documentation

2.7 Assumptions and Dependencies

3 System Features

3.1 User Background Information

3.2 Data Discovery

3.3 IDR Dashboard

3.4 IDR Request

3.5 Data Request Status

3.6 BA Workbench

3.7 IDR Request (copied)

3.8 Mapping

4 External Interface Requirements

4.1 User Interfaces

4.2 Hardware Interfaces

4.3 Software Interfaces

4.4 Communications Interfaces

5 Other Nonfunctional Requirements

5.1 Performance Requirements

5.2 Security Requirements

5.3 Software Quality Attributes

6 Other Requirements

7 Terminology

Appendix A: Analysis Models

Appendix B: Issues List

1         Introduction

1.1     Purpose

In the current research environment, a myriad of independent data repositories exist with various types and amounts of data, and very little ability to integrate that data for clinical research.  I2b2/HOM will give researchers the ability to perform data extraction across a wide variety of systems. 

This document contains the specifications on how the extract data from a secured PHI environment to a secured environment, cleansing the data of PHI. 

This specification document may be a living document as updated process and architectural changes may affect original design and/or scope. 

1.2     Intended Audience

This specifications document is intended for I2b2/HOM architects, I2b2/HOM developers, I2b2/HOM integrated systems developers, business analysts, the user community (beta), and testers.

1.3     Project Scope

Biomedical research basically encompasses four distinct research arenas: 1) clinical research, 2) population research, 3) animal research and 4) bench research. Research in all four arenas is fundamentally necessary to reach the common goal of improving individual and population health. A researcher may utilize more than one research arena for a specific research project.

I2b2/HOM is foreseen to be utilized for another purpose as well. Clinicians, who are administering patient care at the ‘bedside’, would be able to use i2b2/HOM ‘in-real’ time to pull up relevant information in regard to general patient characteristics and treatment profiles for specific diseases and conditions.

1.4     References

Technology Transfer (Data Warehouse) Office

<List any other documents or Web addresses to which this document refers. These may include user interface style guides, contracts, standards, system requirements specifications, use case documents, or a vision and scope document. Provide enough information so that the reader could access a copy of each reference, including title, author, version number, date, and source or location.

Include guide to how to connect site specific data via ETL, etc.>

2         Overall Description

2.1     Product Perspective

At the very beginning of the research enterprise it is common for a researcher to set out to validate certain hypothesized correlations between data elements collected from disparate sources.  Until now it has been very difficult to quickly and effectively look for the possible existence of these ad-hoc correlations.  However, with i2b2/HOM it will be possible for a biomedical investigator to gain access to comprehensive data and very quickly establish the relevance of a hypothesis or a biomedical research idea.

I2b2/HOM serves as the initial point for which a researcher can view what data is available to him/her.  Through a series of queries and data information elements, the researcher can request specific data elements (based on their search), and in the format for which the researcher requests.

Correlations between data elements don’t really prove anything.  However they can be used to bolster the case that a specific line of inquiry may have merit. 

Access to custom user interfaces (UIs) for Time Domain Query, Genetic Epidemiology, etc. (depending on the researcher’s Domain) to refine these speculative hypotheses is extremely useful.  Prior to the conduct of a study and during the process of writing the clinical protocol a study design phase is typically conducted. 

I2b2/HOM as a general purpose data mining tool is extremely helpful to do large numbers of ad-hoc queries to aid in the study design. Also, during the study design phase the researcher may typically require access to a statistical software package such as SAS, STATA or SPSS; thus, secure access can also be provided for data extraction and analysis in the pre-research phase.

The researcher provides the documentation given by the IRB to the Business Analyst (BA) associated with i2b2/HOM as proof of sufficient access privileges. With IRB approval for access to PHI, an identified set of patients will be obtained and the process of recruitment of patients into the trial will begin.  The Business Analyst will provide the researcher with a more accurate list of patients.

2.2     Product Features

I2b2/HOM consists of the following features:

2.3     User Classes and Characteristics

Principal Investigator (PI) - The PI is ultimately responsible for all aspects of conducting the research/clinical study, including knowledge and approval of all co-investigators, collaborators and staff researchers and the supervision and permission of all staff to who study responsibilities including access to i2b2 housed data are delegated. While the PI may delegate responsibilities as appropriate, it is the PI who is responsible for ensuring that all research activities are carried out correctly. 

Project Researcher - Co-investigators and postdoctoral fellows, and other outside research collaborators, such as, Academic Coordinators, Research/Project Managers, Clinical Study Coordinators, Research Assistants, IT programmers, and students who have been PI approved and designated having fulfilled all CHR training and certification requirements can gain access to the i2b2 housed relevant study data sources.

IDR System Administrator - Members of the ARS/IT group who have been given responsibility of maintenance, configuration, and administration of i2b2/HOM.  System Administrators are responsible for following practice in granting access rights to the i2b2/HOM.

2.4     Operating Environment

<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.>

2.5     Design and Implementation Constraints

<Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software).>

2.6     User Documentation

TBD

<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.>

2.7     Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated in this document. These could include third-party or commercial components that you plan to use; issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the vision and scope document or the project plan).>

3         System Features

3.1     User Background Information

3.1.1                         Description and Priority

User Background Information is used to store PI and Researcher information and that data is used throughout the i2b2/HOM user interface.  This page is for user benefit and data storage only, so the user will not have to re-enter his/her data on subsequent pages in the data flow.

This page of data is not considered a priority as PI/Researcher data must be supplied prior to obtaining IRB approval for data requests.  User Background Information is required on the IRB Request page.

3.1.2                         Stimulus/Response Sequences

User Background Information page elements are as follows:

3.1.3                         Functional Requirements

3.2     Data Discovery

3.2.1                         Description and Priority

3.2.2                         Stimulus/Response Sequences

3.2.3                         Functional Requirements

3.3     HOM Dashboard

3.3.1                         Description and Priority

I2b2/HOM Dashboard serves as the “go to” point for all previous data queries and IDR data requests for each user.  I2b2/HOM Dashboard is separated into 3 areas:

The Saved Query area displays all previously saved queries, and users are able to use those queries, edit them, and/or submit them for IDR requests, and/or saved them again for future use.  Users are also able to delete any of their queries to clean up their queue.

The Pending Requests area displays any IDR requests that is in process, and shows the request status (via visual indicator) of each request.  User is also able to use a pending request to create a new request from this area.

The Processed Requests area reflects all completed requests, which users may view, or use to create a new request.

I2b2/HOM Dashboard is a medium priority, as it serves as a “nice to have” function for the user.  The dashboard offers the ability to quickly view all past inquiries, their status, as well as, re-use them for future requests, thus saving time and money for the PI/Researcher, as well as the BA.

3.3.2                         Stimulus/Response Sequences

3.3.3                         Functional Requirements

3.4     HOM Request

3.4.1                         Description and Priority

I2b2/HOM Request page includes all of the data elements that are used to obtain IDR data approval.  This page details specific research study information and selected study criteria provided by the researcher to the BA to submit for IRB approval.

The researcher has the opportunity to edit the requested study criteria, save i2b2/HOM Request to submit at a later time, and the option to submit the request to the BA, to process.

I2b2/HOM Request page is a high priority, as this is where the data to obtain IDR approval is input/stored.  This process initiates a workflow process for the BA to work the request for data.

3.4.2                         Stimulus/Response Sequences

3.4.3                         Functional Requirements

3.5     Data Request Status

3.5.1                         Description and Priority

The Data Request Status page allows the researcher to view the detailed status of their selected request, initiate a new communication, and view all communications to, and from, the BA.

The Data Request Status page is a low priority, as the researcher also has rudimentary status of their data requests from i2b2/HOM Dashboard.

3.5.2                         Stimulus/Response Sequences

3.5.3                         Functional Requirements

3.6     BA Workbench

3.6.1                         Description and Priority

TBD

3.6.2                         Stimulus/Response Sequences

3.6.3                         Functional Requirements

3.7     HOM Request (copied)

3.7.1                         Description and Priority

I2b2/HOM Request (generated from a previous request), allows the researcher to edit elements of an old request to a new request.

This is considered a medium priority as it serves as a “nice to have” for the researcher, but saves time and money for both the researcher and BA.

3.7.2                         Stimulus/Response Sequences

3.7.3                         Functional Requirements

3.8     Mapping

3.8.1                         Description and Priority

The Mapping page offers the researcher encoding options for their requested data.

The Selected Data Summary area reflects the native encoding of their selected data, as well as any, selected mappings by the researcher.

The Available Mappings area reflects mapping types currently available for each data criteria/parameters selected.  The researcher then, selects the encoding for which they would like the resulting data from i2b2/HOM Request.  The requested encodings will then reflect on the Selected Data Summary area, as well.

The researcher may also add a custom mapping in the Available Mappings area in order to request their resulting data in that format.

The Historical Mappings area is a reflection of all mappings generated over the whole IDR researcher population, for those selected data criteria.  This serves useful as IF a certain mapping has already been created for the selected data, the researcher will save money and time, by its reuse by the BA, in processing their request.

3.8.2                         Stimulus/Response Sequences

3.8.3                         Functional Requirements

4         External Interface Requirements

4.1     User Interfaces

<Enter screen shots of all user interfaces>

4.2     Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used.>

4.3     Software Interfaces

<Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint.>

4.4     Communications Interfaces

<Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.>

5         Other Nonfunctional Requirements

5.1     Performance Requirements

<If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features.>

5.2     Security Requirements

<Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.>

5.3     Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning.>

6         Other Requirements

<Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>

7         Terminology

Academic Research Systems technical terminology can be found in:  ARS Glossary and Definitions

Appendix A: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams .>

Appendix B: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts