Main Page

2016-08-04T20:29:49Z

Ehartz01: /* Interview Introduction */

User Personae

2016-08-04T14:00:30Z

Ehartz01: /* Integrative Cancer Biologists and Modelers */

Presented here is a series of stakeholder or user descriptions - referred to here as personae, which informed preliminary development of the cancer models.

==Translational Scientist with “Dry Bench” Bioinformatics skills==

===Background===
* PhD trained scientist in wide range of fields relevant to cancer (e.g. genetics, pharmacology, molecular biology, immunology)
* Analytically trained and familiar with statistical methods, including genomics/bioinformatics.
* Unfamiliar with Natural Language Processing (NLP) Concepts
* Unfamiliar with NLP tools and resources
* Limited familiarity with OO programming languages
* Familiar with text manipulation languages ( e.g. Python, Perl, Ruby)

===Premise/Story===
Cancer biologists are unraveling the genomic and molecular changes that drive tumors towards specific behaviors such as progression and metastasis. Identifying these molecular drivers will require information about the specific cancer behaviors that they produce. This class of users will examine data for case finding and to classify cases based on outcome.

===Expectations===
*Population-level statistics, summarization, and comparisons.
*Graphical displays, including bar charts, error bars, etc.
*Inferential statistics
*Export to statistical software (SAS,SPSS,RapidMiner, R) ###Information needs
*Demographic data
*Treatment data
*Disease progression, metastasis and other outcomes (e.g. RECIST criteria)
*Available biomarkers and other clinical molecular information not in structured format (e.g. Oncotype Scores) ###Current tools and limitations
*Mac desktop, Linux and Windows computing
*Some familiarity with DBMS and data management principles
*Knowledge and use of statistical software (e.g. SAS, SPSS, RapidMiner, R), but time required to extract and format data is substantial.
*Routine access to PHI clinical text for work, able to interpret clinical text reports, but in-depth review is too error-prone and time-consuming.

==Clinical Translational Scientist==

===Background===

* MD, DrPH, or RN trained scientist in wide range of clinical specialties (e.g. oncology, surgery, medicine, pathology, epidemiology)
* Expert understanding of clinical oncology, cancer therapeutics, and patient management
* Familiar with statistical methods, including genomics/bioinformatics, but typically relies on statisticians, bioinformaticists and other collaborators and colleagues for analysis.
* Unfamiliar with NLP Concepts
* Unfamiliar with NLP tools and resources
* Unfamiliar with OO programming languages
* Unfamiliar with text manipulation languages ( e.g. Python, Perl, Ruby)

===Premise/story===

This class of users is interested in extracting phenotype features from a set of documents, often for correlating specific features, treatments, and/or outcomes with molecular characterizations of tumors. They may also be interested in risk factors and other co-morbidities that provide insight into cancer biology (e.g. immune function). Cares more about the quality of the phenotype information in relation to the quality of the scientific conclusions to be developed,rather than the details of the phenotype extraction methods.

===Expectations===

* Basic inferential statistics, summarization, and comparisons.
* Graphical displays, including bar charts, error bars, etc.

===Information needs===

* Demographic data
* Treatment data
* Disease progression, metastasis and other outcomes (e.g. RECIST criteria)
* Available biomarkers and other clinical molecular information not in structured format (e.g. Oncotype Scores)

===Current tools and limitations===

* Enterprise Windows computing
* Limited familiarity with DBMS and data management principles
* Use of statistical software (e.g. SAS, SPSS, RapidMiner, R), but time required to extract and format data is substantial.
* Routine access to PHI clinical text for work, able to interpret clinical text reports. Most able to interpret complex temporal and other relations in text, but in-depth review is too error-prone and time-consuming.

==Population Health Scientist/Health Care Outcomes Analyst==

===Background===

* Broad possibilities, including MD, PhD, MPH/DrPH, MBA.
*Analytically trained and familiar with statistical methods, but not necessarily in genomics/bioinformatics.
* Unfamiliar with NLP Concepts
* Unfamiliar with NLP tools and resources
* Unfamiliar with OO programming languages
* Unfamiliar with text manipulation languages ( e.g. Python, Perl, Ruby)
* Routine access to PHI clinical text for work, easily interprets clinical text reports
* Some familiarity with DBMS and data management principles
* Cares more about accuracy of results, confidence in results, summary information, pointers to WHY particular calls were made (chain of evidence) than the details of the implementation.

===Premise/story===

Cancer care has significant implications in terms of costs of care, effectiveness of different treatments, and values assigned to different outcomes. This class of users will examine data to study efficacy of treatment regimes across different patient groups, to identify factors that might influence costs or improve outcomes, and to otherwise understand how to allocate limited resources to optimize outcomes.

===Expectations===

* Population-level statistics, summarization, and comparisons.
* Graphical displays, including bar charts, error bars, etc.
* Basic inferential statistics
* Export to statistical software (SAS,SPSS, S+, RapidMiner, R)

===Information needs===

* Demographic data
* Treatment data
* Disease progress
* Outcomes
* Treatment context: physician, ward, etc.

===Current tools and limitations===

* Windows-based enterprise computing
* Some familiarity with DBMS and data management principles
* Knowledge and use of statistical software (e.g. SAS, SPSS, S+, RapidMiner), but time required to extract and format data is substantial.
* Routine access to PHI clinical text for work, able to interpret clinical text reports, but in-depth review is too error-prone and time-consuming.

==Information Broker==

===Background===

* Unfamiliar with NLP Concepts
* Unfamiliar with NLP tools and resources
* Unfamiliar with OO programming languages
* Unfamiliar with text manipulation languages (e.g. Python, Perl, Ruby)
* Familiar with DBMS and data management principles
* Limited or no ability to interpret clinical text reports
* Premise/story

This class is comprised of users who are employed at medical research institutions, educational institutions and software companies interested in the healthcare domain. Their daily job involves oversight of data storage solutions. They work with other user groups to identify data requirements and design data storage format, media, and access. They may be open to using existing tools and methods as part of their solutions, but prefer to stick to their established tools for and types of filesystems, shares, databases, etc., as well as their currently used methods for storage and retrieval. Their integration would be limited to accepting NLP output and storing it, possibly in a modified form, or providing mechanisms for NLP output providers to do so themselves. The Information Broker may act as a middleman between NLP output providers and NLP output end users. Success, by the Information Broker's definition, is a simple and consistent tool or method for the migration of NLP output data to a store from which that data is easily accessible by end users.

===Expectations===

* Documentation about the types and formats of NLP output.
* NLP output must be easy to integrate into their own data storage formats.

===Information needs===

* Information needs are dictated by the end users.

===Information constraints===

* The Information Broker should be able to work with a wide variety of standard data types and formats.
* The Information Broker should not be expected to work with any data type and format not of their choosing.

===Current tools and limitations===

* May not have consistent or in-depth communication with end users.
* May not have a complete understanding of what types of data end users may desire.
* Wide array of system environments, databases and tools may be used.
* Lack of standard NLP output data types make it hard to create a universal storage format.
* Lack of standard NLP output data formats make it hard to identify or create universal tools and methods for NLP data consumption.

==Informatics Researcher==

===Background===

* Familiar with NLP Concepts
* Familiar with NLP tools and resources
* Familiar with OO programming languages, but typically not expert
* Familiar with text manipulation languages ( e.g. Python, Perl, Ruby), but typically not expert
* Limited or no ability to interpret clinical text reports *Familiar with basic statistical analyses

===Premise/story===

This class is comprised of users who are employed at medical research institutions, educational institutions, companies in the medical industry and software companies interested in the healthcare domain. They are interested in research and development in the NLP domain, which may or may not be their full-time job. Specific Interests will vary from NLP efficiency to output coverage and accuracy. Their goal is to run software as a finished product in order to develop and test new applications of technology, and they are more interested in assembling workflows and changing parameters than modifying and extending code.

===Expectations===

* Documentation about the types and formats of NLP input and output.
* Documentation about the NLP software and model implementation.
* Documentation about NLP system tests and results.
* Documentation about the available NLP software configuration parameters.
* NLP software is easy to install, configure, and run "out of the box".

===Information needs===

* UMLS type Named Entities
* Temporal Expressions
* Temporal Events
* Temporal Relations
* Information constraints

* The Informatics Researcher must be able to utilize at least one standard cTakes data format: UIMA Cas, XMI file.

===Current tools and limitations===

* Wide array of system environments and tools may be used.
* May not have experience with cTakes or UIMA.

==NLP Developers==

===Background===

* 2-3 years experience working as a programmer, at least 6 months in the NLP domain.
* Familiar with NLP Concepts
* Familiar with NLP tools and resources
* Familiar with programming languages
* Limited or no ability to interpret clinical text reports
* Familiar with basic statistical analyses, particularly with respect to evaluation of NLP models.

===Premise/story===

This class of users are employed at medical research institutions, educational institutions and software companies interested in the healthcare domain. Their daily job involves writing NLP algorithms and systems to extract information from free text. They work with other user groups like domain scientists to identify the data source and type of information that needs extraction. To make their life easier, they are willing to to get under the hood, modify and extend existing software, modify algorithms and extraction targets to suit their needs.

===Expectations===

* Open source software
* Documentation about the features and limitations of the tools/libraries.
* Tutorials and instructions on configuring/customizing the software to their needs.
* Software must be easy to integrate into their own code.
* Tutorials and code samples on extending the software.

===Current tools and limitations===

* GATE, UIMA, various NLP algorithms and libraries.
* Lack of standardization makes it hard to integrate and use different tools and libraries with each other.

==Domain Specific Application Developers==

===Background===

* 2-3 years experience working as a programmer.
* Unfamiliar with NLP Concepts
* Unfamiliar with NLP tools and resources
* Familiar with programming languages
* Limited or no ability to interpret clinical text reports

===Premise/story===

This class of users are employed at medical research institutions, educational institutions and software companies interested in the healthcare domain. Their daily job involves writing code for software applications/tools. They work with other user groups to identify the requirements and design software solutions. They are open to using existing tools/libraries as part of their solutions. Their integration would be limited to using the NLP modules as black boxes, writing input and output translators to plugin these modules into their solutions.

===Expectations===

* Documentation about the features and limitations of the tools/libraries.
* Tutorials and instructions on configuring/customizing the software to their needs.
* Software must be easy to integrate into their own code.

===Current tools and limitations===

* Wide array of IDEs and libraries may be used.
* Lack of standardization makes it hard to integrate and use different tools and libraries with each other.

==Integrative Cancer Biologists and Modelers==

===Background===

* MD, PhD, MPH/DrPH.
* Broad knowledge of cancer biology
* Analytically trained and familiar with statistical and modeling methods
* Some knowledge of genomics/bioinformatics data and analysis methods.
* Familiar with OO and other programming languages
* Unfamiliar with NLP Concepts
* Unfamiliar with NLP tools and resources
* May not be familiar with text manipulation languages ( e.g. Python, Perl, Ruby)
* May not be familiarity with DBMS and data management principles
* Cares more about accuracy of results, confidence in results, summary information, pointers to WHY particular calls were made (chain of evidence) than the details of the implementation.
* Limited or no ability to interpret clinical text reports

===Premise/story===

The user (or team) could tackle questions about the evolutionary history of tumors in response to treatment. Metastasis is usually the killer of cancer patients. Usually treatment resistance mechanisms appear and tumors become ever more refractory. Thus a combination of systems biology and tumor population dynamics modeling could address important treatment questions, if detailed longitudinal clinical data are coupled to tumor genomics.

===Expectations===

* Ability to download or otherwise access data in a form suitable for processing.

===Information needs===

* Demographic, clinico-pathologic and comorbidity data
* Detailed treatment data
* Detailed disease progression data, including censoring dates
* Outcomes
* Genomic and other bioinformatics data when available.

User Personae

2016-08-04T13:59:07Z

Ehartz01: /* Domain Specific Application Developers */

User Personae

2016-08-04T13:58:00Z

Ehartz01: /* NLP Developers */

User Personae

2016-08-03T19:03:16Z

Ehartz01: /* Informatics Researcher */

Presented here is a series of stakeholder or user descriptions - referred to here as personae, which informed preliminary development of the cancer models.

==Translational Scientist with “Dry Bench” Bioinformatics skills==

===Background===
* PhD trained scientist in wide range of fields relevant to cancer (e.g. genetics, pharmacology, molecular biology, immunology)
* Analytically trained and familiar with statistical methods, including genomics/bioinformatics.
* Unfamiliar with Natural Language Processing (NLP) Concepts
* Unfamiliar with NLP tools and resources
* Limited familiarity with OO programming languages
* Familiar with text manipulation languages ( e.g. Python, Perl, Ruby)

===Premise/Story===
Cancer biologists are unraveling the genomic and molecular changes that drive tumors towards specific behaviors such as progression and metastasis. Identifying these molecular drivers will require information about the specific cancer behaviors that they produce. This class of users will examine data for case finding and to classify cases based on outcome.

===Expectations===
*Population-level statistics, summarization, and comparisons.
*Graphical displays, including bar charts, error bars, etc.
*Inferential statistics
*Export to statistical software (SAS,SPSS,RapidMiner, R) ###Information needs
*Demographic data
*Treatment data
*Disease progression, metastasis and other outcomes (e.g. RECIST criteria)
*Available biomarkers and other clinical molecular information not in structured format (e.g. Oncotype Scores) ###Current tools and limitations
*Mac desktop, Linux and Windows computing
*Some familiarity with DBMS and data management principles
*Knowledge and use of statistical software (e.g. SAS, SPSS, RapidMiner, R), but time required to extract and format data is substantial.
*Routine access to PHI clinical text for work, able to interpret clinical text reports, but in-depth review is too error-prone and time-consuming.

==Clinical Translational Scientist==

===Background===

* MD, DrPH, or RN trained scientist in wide range of clinical specialties (e.g. oncology, surgery, medicine, pathology, epidemiology)
* Expert understanding of clinical oncology, cancer therapeutics, and patient management
* Familiar with statistical methods, including genomics/bioinformatics, but typically relies on statisticians, bioinformaticists and other collaborators and colleagues for analysis.
* Unfamiliar with NLP Concepts
* Unfamiliar with NLP tools and resources
* Unfamiliar with OO programming languages
* Unfamiliar with text manipulation languages ( e.g. Python, Perl, Ruby)

===Premise/story===

This class of users is interested in extracting phenotype features from a set of documents, often for correlating specific features, treatments, and/or outcomes with molecular characterizations of tumors. They may also be interested in risk factors and other co-morbidities that provide insight into cancer biology (e.g. immune function). Cares more about the quality of the phenotype information in relation to the quality of the scientific conclusions to be developed,rather than the details of the phenotype extraction methods.

===Expectations===

* Basic inferential statistics, summarization, and comparisons.
* Graphical displays, including bar charts, error bars, etc.

===Information needs===

* Demographic data
* Treatment data
* Disease progression, metastasis and other outcomes (e.g. RECIST criteria)
* Available biomarkers and other clinical molecular information not in structured format (e.g. Oncotype Scores)

===Current tools and limitations===

* Enterprise Windows computing
* Limited familiarity with DBMS and data management principles
* Use of statistical software (e.g. SAS, SPSS, RapidMiner, R), but time required to extract and format data is substantial.
* Routine access to PHI clinical text for work, able to interpret clinical text reports. Most able to interpret complex temporal and other relations in text, but in-depth review is too error-prone and time-consuming.

==Population Health Scientist/Health Care Outcomes Analyst==

===Background===

* Broad possibilities, including MD, PhD, MPH/DrPH, MBA.
*Analytically trained and familiar with statistical methods, but not necessarily in genomics/bioinformatics.
* Unfamiliar with NLP Concepts
* Unfamiliar with NLP tools and resources
* Unfamiliar with OO programming languages
* Unfamiliar with text manipulation languages ( e.g. Python, Perl, Ruby)
* Routine access to PHI clinical text for work, easily interprets clinical text reports
* Some familiarity with DBMS and data management principles
* Cares more about accuracy of results, confidence in results, summary information, pointers to WHY particular calls were made (chain of evidence) than the details of the implementation.

===Premise/story===

Cancer care has significant implications in terms of costs of care, effectiveness of different treatments, and values assigned to different outcomes. This class of users will examine data to study efficacy of treatment regimes across different patient groups, to identify factors that might influence costs or improve outcomes, and to otherwise understand how to allocate limited resources to optimize outcomes.

===Expectations===

* Population-level statistics, summarization, and comparisons.
* Graphical displays, including bar charts, error bars, etc.
* Basic inferential statistics
* Export to statistical software (SAS,SPSS, S+, RapidMiner, R)

===Information needs===

* Demographic data
* Treatment data
* Disease progress
* Outcomes
* Treatment context: physician, ward, etc.

===Current tools and limitations===

* Windows-based enterprise computing
* Some familiarity with DBMS and data management principles
* Knowledge and use of statistical software (e.g. SAS, SPSS, S+, RapidMiner), but time required to extract and format data is substantial.
* Routine access to PHI clinical text for work, able to interpret clinical text reports, but in-depth review is too error-prone and time-consuming.

==Information Broker==

===Background===

* Unfamiliar with NLP Concepts
* Unfamiliar with NLP tools and resources
* Unfamiliar with OO programming languages
* Unfamiliar with text manipulation languages (e.g. Python, Perl, Ruby)
* Familiar with DBMS and data management principles
* Limited or no ability to interpret clinical text reports
* Premise/story

This class is comprised of users who are employed at medical research institutions, educational institutions and software companies interested in the healthcare domain. Their daily job involves oversight of data storage solutions. They work with other user groups to identify data requirements and design data storage format, media, and access. They may be open to using existing tools and methods as part of their solutions, but prefer to stick to their established tools for and types of filesystems, shares, databases, etc., as well as their currently used methods for storage and retrieval. Their integration would be limited to accepting NLP output and storing it, possibly in a modified form, or providing mechanisms for NLP output providers to do so themselves. The Information Broker may act as a middleman between NLP output providers and NLP output end users. Success, by the Information Broker's definition, is a simple and consistent tool or method for the migration of NLP output data to a store from which that data is easily accessible by end users.

===Expectations===

* Documentation about the types and formats of NLP output.
* NLP output must be easy to integrate into their own data storage formats.

===Information needs===

* Information needs are dictated by the end users.

===Information constraints===

* The Information Broker should be able to work with a wide variety of standard data types and formats.
* The Information Broker should not be expected to work with any data type and format not of their choosing.

===Current tools and limitations===

* May not have consistent or in-depth communication with end users.
* May not have a complete understanding of what types of data end users may desire.
* Wide array of system environments, databases and tools may be used.
* Lack of standard NLP output data types make it hard to create a universal storage format.
* Lack of standard NLP output data formats make it hard to identify or create universal tools and methods for NLP data consumption.

==Informatics Researcher==

===Background===

* Familiar with NLP Concepts
* Familiar with NLP tools and resources
* Familiar with OO programming languages, but typically not expert
* Familiar with text manipulation languages ( e.g. Python, Perl, Ruby), but typically not expert
* Limited or no ability to interpret clinical text reports *Familiar with basic statistical analyses

===Premise/story===

This class is comprised of users who are employed at medical research institutions, educational institutions, companies in the medical industry and software companies interested in the healthcare domain. They are interested in research and development in the NLP domain, which may or may not be their full-time job. Specific Interests will vary from NLP efficiency to output coverage and accuracy. Their goal is to run software as a finished product in order to develop and test new applications of technology, and they are more interested in assembling workflows and changing parameters than modifying and extending code.

===Expectations===

* Documentation about the types and formats of NLP input and output.
* Documentation about the NLP software and model implementation.
* Documentation about NLP system tests and results.
* Documentation about the available NLP software configuration parameters.
* NLP software is easy to install, configure, and run "out of the box".

===Information needs===

* UMLS type Named Entities
* Temporal Expressions
* Temporal Events
* Temporal Relations
* Information constraints

* The Informatics Researcher must be able to utilize at least one standard cTakes data format: UIMA Cas, XMI file.

===Current tools and limitations===

* Wide array of system environments and tools may be used.
* May not have experience with cTakes or UIMA.

==NLP Developers==

==Domain Specific Application Developers==

==Integrative Cancer Biologists and Modelers==

User Personae

2016-08-03T17:23:20Z

Ehartz01: /* Information Broker */

User Personae

2016-08-03T15:37:14Z

Ehartz01: /* Current tools and limitations */

User Personae

2016-08-03T15:36:54Z

Ehartz01: /* Population Health Scientist/Health Care Outcomes Analyst */

2016-06-15T15:05:19Z

Ehartz01: /* DeepPhe Ontology Models */

==Welcome to DeepPhe==

Cancer is a genomic disease, with enormous heterogeneity in its behavior. In the past, our methods for categorization, prediction of outcome, and treatment selection have relied largely on a morphologic classification of Cancer. But new technologies are fundamentally reframing our views of cancer initiation, progression, metastasis, and response to treatment; moving us towards a molecular classification of Cancer. This transformation depends not only on our ability to deeply investigate the cancer genome, but also on our ability to link these specific molecular changes to specific tumor behaviors. As sequencing costs continue to decline at a supra-Moore’s law rate, a torrent of cancer genomic data is looming. However, our ability to deeply investigate the cancer genome is outpacing our ability to correlate these changes with the phenotypes that they produce. Translational investigators seeking to associate specific genetic, epigenetic, and systems changes with particular tumor behaviors, lack access to detailed observable traits about the cancer (the so called ‘deep phenotype’), which has now become a major barrier to research.

We propose the advanced development and extension of a software platform for performing deep phenotype extraction directly from medical records of patients with Cancer, with the goal of enabling translational cancer research and precision medicine. The work builds on previous informatics research and software development efforts from Boston Children’s Hospital and University of Pittsburgh groups, both individually and together. Multiple software projects developed by our groups (some initially funded by NCI) that have already passed the initial prototyping and pilot development phase (eMERGE, THYME, TIES, ODIE, Apache cTAKES) will be combined and extended to produce an advanced software platform for accelerating cancer research. Previous work in a number of NIH-funded translational science initiatives has already demonstrated the benefits of these methodologies (e.g. Electronic Medical Record and Genomics (eMERGE), PharmacoGenomics Research Network (PGRN), SHARPn, i2b2). However, to date these initiatives have focused exclusively on select non-cancer phenotypes and have had the goal of dichotomizing patients for a particular phenotype of interest (for example, Type II Diabetes, Rheumatoid Arthritis, or Multiple Sclerosis). In contrast, our proposed work focuses on extracting and representing multiple phenotype features for individual patients, to build a cancer phenotype model, relating observable traits over time for individual patients.

Our first four development specific aims significantly extend the capability of our current software, focusing on challenging problems in biomedical information extraction. These aims support the development and evaluation of novel methods for cancer deep phenotype extraction:

'''Specific Aim 1''': Develop methods for extracting phenotypic profiles. Extract patient’s deep phenotypes, and their attributes such as general modifiers (negation, uncertainty, subject) and cancer specific characteristics (e.g. grade, invasion, lymph node involvement, metastasis, size, stage)

'''Specific Aim 2''': Extract gene/protein mentions and their variants from the clinical narrative

'''Specific Aim 3''': Create longitudinal representation of disease process and its resolution. Link phenotypes, treatments and outcomes in temporal associations to create a longitudinal abstraction of the disease

'''Specific Aim 4''': Extract discourses containing explanations, speculations, and hypotheses, to support explorations of causality

Our last two implementation specific aims focus on the design of the software to support the cancer research community, ensuring the usability and utility of our software. These aims support the design, dissemination and sharing of the products of this work to maximize impact on cancer research:

'''Specific Aim 5''': Design and implement a computational platform for deep phenotype discovery and analytics for translational investigators, including integrative visual analytics.

'''Specific Aim 6''': Advance translational research in driving cancer biology research projects in breast cancer, ovarian cancer, and melanoma. Include research community throughout the design of the platform and its evaluation. Disseminate freely available software.

'''''Impact:''''' The proposed work will produce novel methods for extracting detailed phenotype information directly from the EMR, the major source of such data for patients with cancer. Extracted phenotypes will be used in three ongoing translational studies with a precision medicine focus. Dissemination of the software will enhance the ability of cancer researchers to abstract meaningful clinical data for translational research. If successful, systematic capture and representation of these phenotypes from EMR data could later be used to drive clinical genomic decision support.

==Who We Are==

'''Boston Childrens Hospital/Harvard Medical School'''

*Guergana Savova (MPI)

*Dmitriy Dligach

*Timothy Miller

*Sean Finan

*David Harris

*Chen Lin

'''University of Pittburgh'''

*Rebecca Crowley Jacobson (MPI)

*Harry Hochheiser

*Roger Day

*Adrian Lee

*Robert Edwards

*John Kirkwood

*Kevin Mitchell

*Eugene Tseytlin

*Girish Chavan

*Liz Legowski (through Jan 2015)

*Melissa Castine

==Publications and Presentations==

The following are publications and presentations crediting the Cancer Deep Phenotype Extraction ('''DeepPhe''') project:

* Hochheiser H; Jacobson R; Washington N; Denny J; Savova G. 2015. Natural language processing for phenotype extraction: challenges and representation. AMIA Annual Symposium. Nov 2015, San Francisco, CA.
* Dmitriy Dligach, Timothy Miller, Guergana K. Savova. 2015. Semi-supervised Learning for Phenotyping Tasks. AMIA Annual Symposium. Nov 2015, San Francisco, CA.
* Chen, Lin; Dligach, Dmitriy; Miller, Timothy; Bethard, Steven; Savova, Guergana. 2015. Layered temporal modeling for the clinical domain. Journal of the American Medical Informatics Association. http://jamia.oxfordjournals.org/content/early/2015/10/31/jamia.ocv113

==Funding==

The project described is supported by Grant Number 1U24CA184407-01 from the National Cancer Institute at the US National Institutes of Health. This work is part of the NCI's Informatics Technology for Cancer Research (ITCR) Initiative (http://itcr.nci.nih.gov/) The content is solely the responsibility of the authors and does not necessarily represent the official views of the National Institutes of Health.

The project period is May 2014 - April, 2019.

==Stakeholder Information==

===User Personae===
[[User Personae]]

===Contextual Interview Protocol===

===Information modeling interview protocol===

===Competency questions===

===Contextual Design Information===
See presentation here: [[https://healthnlp.hms.harvard.edu/cancer/wiki/images/3/35/Cd-quick-intro-201408110918.pdf]]

==Licensing==

===Goals===

* Encourage the broad use of DeepPhe tools and models, while maintaining openness and attribution.
* Comply with resource sharing plan as submitted to NIH. See, for example [ITCR policies](http://itcr.nci.nih.gov/about-itcr)

===Distinction===

We are reading "software" as referring to executable components, while "models" refers to the OWL data models developed for representation of cancer phenotypes.

===Licensing of Software===

* cTAKES is licensed under the Apache Source License 2.0
* DeepPhe cTAKES components will be similarly licensed
* Other DeepPhe components will be licensed by some open source license, potentially (but not necessarily) the Apache license.

===Licensing of Other Models===

* List of non-software licenses -- https://en.wikipedia.org/wiki/List_of_free_content_licenses
** Licensing for content are appropriate
* Principles
** receive credit for what we do
** allow other people to contribute (not just take it and use it) -> share alike
* Creative Commons
** Creative Commons does not recommend the use of Creative Commons licenses for software.
** https://en.wikipedia.org/wiki/Creative_Commons_license
** CC BY 2.0 - https://creativecommons.org/licenses/by/2.0/
*** you are free to share and adapt when you give attribution (You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.)
** CC BY 3.0 - http://creativecommons.org/licenses/by/3.0/
** is it compatible with Apache license?
*** CC BY 2.5 and 3.0 are in Category B - http://www.apache.org/legal/resolved.html
*** Unmodified media under the Creative Commons Attribution-Share Alike 2.5 and Creative Commons Attribution-Share Alike 3.0 licenses may be included in Apache products, subject to the licenses attribution clauses which may require LICENSE/NOTICE/README changes. For any other type of CC-SA licensed work, please contact the Legal PMC.
** CY BY 4.0 http://creativecommons.org/licenses/by/4.0/
*** is it compatible with the Apache license? We believe so.. see [this thread](http://apache.markmail.org/search/?q=legal-discuss#query:legal-discuss%20order%3Adate-backward+page:1+mid:3whmjdfqnvukcg2s+state:results)
* Open Content
*** https://en.wikipedia.org/wiki/Open_Content_License -- The Open Content License is a share-alike public copyright license which can be applied to a work to make it open content. This license is not compatible with any other license in that it requires derivative works to be licensed under the Open Content License.
** probably not compatible with Apache.
* Art Libre
**creative works without the author's explicit permission

===DeepPhe Ontology Models===

* DeepPhe Ontology models will be licensed using CC-BY 4.0
* This is consistent with plans to use CC-BY 4.0 to license the schema ontology upon which the DeepPhe model is based.

Main Page

2016-06-15T15:04:54Z

Ehartz01: /* Licensing of Other Models */