- - + - Development Overview + Overview + + +
- + + + + Strategy
-
diff --git a/docs/genomics.html b/docs/genomics.html
index 35437f0..b123581 100644
--- a/docs/genomics.html
+++ b/docs/genomics.html
@@ -346,9 +346,16 @@
- - + - Development Overview + Overview + + +
- + + + + Strategy
-
diff --git a/docs/gettingInvolved.html b/docs/gettingInvolved.html
index 1ef5c8a..78b58c1 100644
--- a/docs/gettingInvolved.html
+++ b/docs/gettingInvolved.html
@@ -346,9 +346,16 @@
- - + - Development Overview + Overview + + +
- + + + + Strategy
-
diff --git a/docs/githubProject.html b/docs/githubProject.html
index e0cbe9a..3cc75ee 100644
--- a/docs/githubProject.html
+++ b/docs/githubProject.html
@@ -346,9 +346,16 @@
- - + - Development Overview + Overview + + +
- + + + + Strategy
-
diff --git a/docs/index.html b/docs/index.html
index e25cf53..6e5d5cb 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -346,9 +346,16 @@
- - + - Development Overview + Overview + + +
- + + + + Strategy
-
@@ -609,13 +616,20 @@
Development Effort
Overview of current development effort + +Strategy +
Delta Vocabulary
Validation FrameworkDetails regarding key components of the development +strategy +Progress Map
Miro Map
RoadmapMiro Map of completed and outstanding work within scope (with links) + Github Project Orientation
Architecture
Development EffortDocumentation about navigating and understanding the Github Project and approach + Getting Involved
Join Collaboration Channels
- - + - Development Overview + Overview + +
+- + + + + Strategy
- diff --git a/docs/model.html b/docs/model.html index 854011c..e936bc5 100644 --- a/docs/model.html +++ b/docs/model.html @@ -346,9 +346,16 @@
- - + - Development Overview + Overview + + +
- + + + + Strategy
-
diff --git a/docs/naaccr.html b/docs/naaccr.html
index d73e11c..698b5ed 100644
--- a/docs/naaccr.html
+++ b/docs/naaccr.html
@@ -346,9 +346,16 @@
- - + - Development Overview + Overview + + +
- + + + + Strategy
-
diff --git a/docs/progressMap.html b/docs/progressMap.html
index 727c109..38bfd09 100644
--- a/docs/progressMap.html
+++ b/docs/progressMap.html
@@ -346,9 +346,16 @@
- - + - Development Overview + Overview + + +
- + + + + Strategy
-
diff --git a/docs/strategy.html b/docs/strategy.html
new file mode 100644
index 0000000..8b8709b
--- /dev/null
+++ b/docs/strategy.html
@@ -0,0 +1,805 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Development Strategy + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ++ + + ++ + + + + + + + + + + + + + + + diff --git a/docs/tooling.html b/docs/tooling.html index 11038b4..4d564e0 100644 --- a/docs/tooling.html +++ b/docs/tooling.html @@ -346,9 +346,16 @@++ +++ ++++ + + + ++++ ++++ ++ ++
OHDSI Oncology WG + + + ++ + +
+ +
+Development Strategy
+
+++Delta Vocabulary
+
+++Context
+-
+
- Support for the Oncology vocabularies was dropped by the central +OHDSI Vocabulary team in 2023. Since then, the responsibility for +maintaining these vocabularies has been assumed by the Oncology +Workgroup +
- We are moving at a faster pace than the official OHDSI vocabulary +releases and consequently will be maintaining a “delta”, or +“development”, version of the vocabularies. At the end of this effort we +plan to have these changes folded back into the standards. Additionally +we will consult with the vocabulary team when applicable. +
+++Details
+
+++Process
+-
+
- Make local edits to the relevant OMOP Vocabulary +tables (concept and concept_relationship) +
- Rebuild concept_ancestor table +programmatically +
- Run validation checks on updated vocabulary to +ensure integrity +
- Export the delta records and push to GitHub +
+++Rationale
+Git and GitHub offer a collaborative environment for proposing, +discussing, and implementing changes to a reference vocabulary such as +the OMOP Vocabulary.
+However, due to licensing and volume issues, it is not possible to +maintain and develop the entire OMOP vocabulary in a GitHub repository +as flat files.
+To work around this, a group of collaborators can maintain and +contribute to a growing list of edits to the OMOP Vocabulary. We call +this list of edits the “delta vocab”.
+The delta vocab, which is literally a collection of concept and +concept_relationship records exactly as they would represented in the +OMOP Vocabulary table, provides a lightweight representation of any +deviations from the official OMOP Vocabulary. From these tables, the +concept_ancestor table is then programmatically generated.
+Maintaining the change between the official OMOP +Vocabulary release and the Oncology Development Vocabulary allows for +rapid development of OHDSI Oncology studies that are untethered from the +official OMOP Vocabulary release cadence. By preserving only the changed +elements, instead of the entire Oncology Development Vocabulary, this +method provides a lightweight, GitHub-friendly solution, that is also +respectful of (by way of avoiding) the licensed vocabulary terms.
+The simplicity of maintaining as little of the vocabulary as possible +and using scripted logic to apply changes to the existing vocabulary +makes this method easy to implement and ideal for the core use case - +establishing standard concepts and remapping newly destandardized +terms.
+
+++Implementation
+Three steps are necessary to deploy the delta vocabularies to your +local database:
+-
+
Download source vocab data and tools
+Configure your local database
+Ingest delta vocabulary files
+
+++Download
+To create the Oncology Development Vocabulary, you must download the +vocabTools +and deltaVocab +folders from the OHDSI/OncologyWG repository. It may be simplest to +clone the OHDSI/OncologyWG and work from there:
+
+git clone https://github.com/OHDSI/OncologyWG.git
+++Configure
+These methods assume you have the latest official release of the OMOP +Vocabulary in two identical schemas in a Postgres database: - +prod: The prod schema contains the +official (“production”) OMOP Vocabulary. This vocabulary will not be +changed but can be used to refresh the dev schema. - +dev: The dev schema begins as an exact +copy of the official OMOP Vocabulary, but will be transformed into the +Oncology Development Vocabulary using the deltaVocab files and the +scripts in vocabTools.
+To enable the scripts in vocabTools, enter your database connection +details into the config.txt file.
+
+++Ingest
+Create two folders in the vocabTools folder: concept and +concept_relationship.
+Move the deltaConcept and deltaConceptRelationship files to the new +concept and concept_relationship folders, respectively.
+Run updateConcept.bat to implement the changes from +deltaConcept to the dev schema in your database.
+Run updateConceptRelationship.bat to implement the +changes from deltaConceptRelationship to the dev schema in your +database.
+Run updateConceptAncestor.bat to rebuild +concept_ancestor based on the new concept and concept_relationship +tables in the dev schema.
+
+++Development
+Using the delta vocab and helper scripts, a developer with an +official OMOP Vocabulary database can quickly create a full, working +version of the OMOP Vocabulary with all proposed changes implemented, +allowing for advanced testing and use of existing OHDSI tools with a +development version of the vocabulary.
++
+See README of the vocabTools +directory for instructions for contributing to the Oncology Delta +Vocabulary
+
+
+++GitHub Project
+A GitHub Project has been created and customized to enable +collaborative and dynamic project management. Notably this project +exists at the organization level, not the repository level, thus +enabling extended functionality including issue triage across multiple +repositories.
++
+Orientation and Onramp: GitHub Project +Orientation
+GitHub Project: Oncology Maturity +Sprint
+
+
+++RMarkdown (docs)
+We leverage the RMarkdown R Package to create content in Rmd files +and generate them as HTML. Through GitHub Pages, these HTML files can be +easily deployed as a project website. There are several options varying +in technical complexity to contribute to this documentation.
++
+See here for more +details
+
+
+++ + + +Validation Framework
+
+++Context
+-
+
- Support the automated execution of scripts that return a simple +signal (stoplight) that indicates whether a necessary component of an +OHDSI study can run without error on appropriate required data content. +Signals comprehensively cover data availability, data quality, and +analytic algorithms specified in an OHDSI study. +
- Signal generation and display can be generated locally and, +optionally, shared centrally in order to facilitate rapid unambiguous +assessment of candidate site’s ability to participate in a study. +
- A version of the same approach might be extended to a +non-study-specific display of a prespecified set of requirements for +formally defined “levels of readiness” for OHDSI oncology studies that +use the OHDSI Oncology 2.0 infrastructure. +
+
+++Details
+
+++Rationale
+Provide a semi-automated and extensible framework for generating, +visualizing, and sharing an assessment of an OMOP-shaped database’s +adherence to the OHDSI Oncology Standard (tables, vocabulary) and the +availabilty and types of oncology data it contains.
+
+++Approach
+Assessments can be executed against an OMOP-shaped database +to create a characterization and quality report. They are created using +specificications.
+Specifications are JSON files that describe an assessment. +They are composed by compiling analyses together with threshhold +values.
+Analyses execute a query and return a row count or +proportion describing the contents in the database. For example, +analysis_id=1234 returns “the number of cancer diagnosis records derived +from Tumor Registry source data”.
+Threshholds provide study specific context to the results of +analyses. An analysis asks how many cancer diagnoses derived from tumor +registry data are in the database. Using threshholds, an assessment +author can give ranges for “bad”, “questionable”, and “good” analysis +results as they pertain to their study. An example threshhold, which +would be encoded as JSON, could express the sentiment “A database with +0-200 diagnoses from tumor registry data would be unfit for this study, +201-500 diagnoses may be suitable, and over 500 diagnoses will be more +enough.”
+
+
+++Implementation
+The R package provides functionality for the four major processes +involved in the framework:
+-
+
- Authoring an assessment specification +
- Executing an assessment specification +
- Generating assessment results +
- Visualizing assessment results +
+
+++Development
++
+See README of the validationScripts +directory for instructions for contributing to the Oncology Validation +Framework
+
+
+- - + - Development Overview + Overview + + +
- + + + + Strategy
-
@@ -513,102 +520,33 @@
OncoRegimenFinder
--Development & Testing
-
--Characterization and Validation
-
---Purpose
-Provide a semi-automated and extensible framework for generating, -visualizing, and sharing an assessment of an OMOP-shaped database’s -adherence to the OHDSI Oncology Standard (tables, vocabulary) and the -availabilty and types of oncology data it contains.
---Overview
-The star of the framework is an R Package. Along with cataloguing an -extensible set of queries and analyses used for assessing OMOP-shaped -oncology data, the R package provides functionality for the four major -processes involved in the framework:
--
-
- Authoring an assessment specification -
- Executing an assessment specification -
- Generating assessment results -
- Visualizing assessment results -
--Approach
-Assessments can be executed against an OMOP-shaped database -to create a characterization and quality report. They are created using -specificications.
-Specifications are JSON files that describe an assessment. -They are composed by compiling analyses together with threshhold -values.
-Analyses execute a query and return a row count or -proportion describing the contents in the database. For example, -analysis_id=1234 returns “the number of cancer diagnosis records derived -from Tumor Registry source data”.
-Threshholds provide study specific context to the results of -analyses. An analysis asks how many cancer diagnoses derived from tumor -registry data are in the database. Using threshholds, an assessment -author can give ranges for “bad”, “questionable”, and “good” analysis -results as they pertain to their study. An example threshhold, which -would be encoded as JSON, could express the sentiment “A database with -0-200 diagnoses from tumor registry data would be unfit for this study, -201-500 diagnoses may be suitable, and over 500 diagnoses will be more -enough.”
--Extensibility
-This tool is a product of collaboration. See the validation scripts -README for detailed instructions on creating analyses (TODO) and using -the R package to author and execute assessment specifications (TODO). -
++-Development
++Delta Vocabulary
+Documentation: Delta +Vocabulary
+Maintaining the change between the official OMOP Vocabulary release +and the Oncology Development Vocabulary allows for rapid development of +OHDSI Oncology studies that are untethered from the official OMOP +Vocabulary release cadence. By preserving only the changed elements, +instead of the entire Oncology Development Vocabulary, this method +provides a lightweight, GitHub-friendly solution, that is also +respectful of (by way of avoiding) the licensed vocabulary terms.
-Delta Vocabulary Framework
-A suite of tools to quickly set up an environment for: 1) making -local edits to the OMOP Vocabularies (concept and concept_relationship -tables) 2) generating derived tables (concept_ancestor) 3) validating -the vocabulary changes 4) outputting the table delta in a sharable -format
++diff --git a/rmd/_site.yml b/rmd/_site.yml index 98fb8e1..916e200 100644 --- a/rmd/_site.yml +++ b/rmd/_site.yml @@ -19,9 +19,12 @@ navbar: - text: " Development Effort" icon: fa-people-group menu: - - text: " Development Overview" + - text: " Overview" href: development.html - icon: fa-map + icon: fa-tower-observation + - text: " Strategy" + href: strategy.html + icon: fa-chess - text: " Progress Map" href: progressMap.html icon: fa-list-check diff --git a/rmd/index.Rmd b/rmd/index.Rmd index 6a6def0..b96a249 100644 --- a/rmd/index.Rmd +++ b/rmd/index.Rmd @@ -73,6 +73,7 @@ This site contains the following sections: | | | | -------- | :----------- | | **[Development Overview](development.html)**Data Quality and Characterization
--+Structure/Approach
-Git and GitHub offer a collaborative environment for proposing, -discussing, and implementing changes to a reference vocabulary such as -the OMOP Vocabulary.
-However, due to licensing and volume issues, it is not possible to -maintain and develop the entire OMOP vocabulary in a GitHub repository -as flat files.
-To work around this, a group of collaborators can maintain and -contribute to a growing list of edits to the OMOP Vocabulary. We call -this list of edits the “delta vocab”.
-The delta vocab, which is literally a collection of concept and -concept_relationship records exactly as they would represented in the -OMOP Vocabulary table, provides a lightweight representation of any -deviations from the official OMOP Vocabulary.
-Using the delta vocab and delta helper scripts, a developer with an -official OMOP Vocabulary database can quickly create a full, working -version of the OMOP Vocabulary with all proposed changes implemented, -allowing for advanced testing and use of existing OHDSI tools with a -development version of the vocabulary.
-The simplicity of maintaining as little of the vocabulary as possible -and using scripted logic to apply changes to the existing vocabulary -makes this method easy to implement, but also limited in its -capabilities. As of now, the primary use for the delta vocab method is -for destandardizing and mapping non-standard terms.
-For details on using the delta vocab and the helper scripts, see the -README and function reference (TODO)
-
-
-+Adoption Validation Framework
+Documentation: Validation Framework
+A semi-automated and extensible framework for generating, +visualizing, and sharing database characterization and adherence to the +OHDSI Oncology Standard Conventions.
[Purpose](development.html#Purpose)
[Goals](development.html#Goals)
[Notable Challenges](development.html#Notable_Challenges)
[Context](development.html#Context)
[Scope](development.html#Scope)
[What we need](development.html#What_we_need)
[Project Management](development.html#Project_Management)| Overview of current development effort | +| **[Strategy](strategy.html)**
[Delta Vocabulary](strategy.html#Delta_Vocabulary)
[Validation Framework](strategy.html#Validation_Framework) | Details regarding key components of the development strategy | | **[Progress Map](progressMap.html)**
[Miro Map](progressMap.html#Miro_Map)
[Roadmap](progressMap.html#Roadmap) | Miro Map of completed and outstanding work within scope (with links) | | **[Github Project Orientation](githubProject.html)**
[Architecture](githubProject.html#Architecture)
[Strategy](githubProject.html#strategy)
[Project Navigation](githubProject.html#Project_Navigation)
[Example Walkthrough](githubProject.html#Approach) | Documentation about navigating and understanding the Github Project and approach | | **[Getting Involved](gettingInvolved.html)**
[Join Collaboration Channels](gettingInvolved.html#join_collaboration_channels)
[Submit Collaborator Form](gettingInvolved.html#Submit_a_new_collaborator_form)
[Review Project Documentation](gettingInvolved.html#Review_Project_Documentation)
[Contributing](gettingInvolved.html#Contributing) | Suggestions and links for getting started in the effort! | diff --git a/rmd/strategy.Rmd b/rmd/strategy.Rmd new file mode 100644 index 0000000..0ebb0cd --- /dev/null +++ b/rmd/strategy.Rmd @@ -0,0 +1,189 @@ +--- +title: '' +output: + html_document: + toc: TRUE + toc_depth: 2 + toc_float: + collapsed: false +--- + +```{r load_packages, message=FALSE, warning=FALSE, include=FALSE} +library(fontawesome) +``` + +--- + + Development Strategy
+ +# **Delta Vocabulary** + +
+ +## Context + - Support for the Oncology vocabularies was dropped by the central OHDSI Vocabulary team in 2023. Since then, the responsibility for maintaining these vocabularies has been assumed by the Oncology Workgroup + - We are moving at a faster pace than the official OHDSI vocabulary releases and consequently will be maintaining a “delta”, or “development”, version of the vocabularies. At the end of this effort we plan to have these changes folded back into the standards. Additionally we will consult with the vocabulary team when applicable. + +--- + +## Details + +
+ +### Process + +1. **Make local edits** to the relevant OMOP Vocabulary tables (concept and concept_relationship) +1. **Rebuild concept_ancestor** table programmatically +1. **Run validation checks** on updated vocabulary to ensure integrity +1. **Export** the delta records and push to GitHub + +
+ +### Rationale +Git and GitHub offer a collaborative environment for proposing, discussing, and implementing changes to a reference vocabulary such as the OMOP Vocabulary. + +However, due to licensing and volume issues, it is not possible to maintain and develop the entire OMOP vocabulary in a GitHub repository as flat files. + +To work around this, a group of collaborators can maintain and contribute to a growing list of edits to the OMOP Vocabulary. We call this list of edits the “delta vocab”. + +The delta vocab, which is literally a collection of concept and concept_relationship records exactly as they would represented in the OMOP Vocabulary table, provides a lightweight representation of any deviations from the official OMOP Vocabulary. From these tables, the concept_ancestor table is then programmatically generated. + +Maintaining the **change** between the official OMOP Vocabulary release and the Oncology Development Vocabulary allows for rapid development of OHDSI Oncology studies that are untethered from the official OMOP Vocabulary release cadence. By preserving only the changed elements, instead of the entire Oncology Development Vocabulary, this method provides a lightweight, GitHub-friendly solution, that is also respectful of (by way of avoiding) the licensed vocabulary terms. + +The simplicity of maintaining as little of the vocabulary as possible and using scripted logic to apply changes to the existing vocabulary makes this method easy to implement and ideal for the core use case - establishing standard concepts and remapping newly destandardized terms. + +--- + +## Implementation + +Three steps are necessary to deploy the delta vocabularies to your local database: + +1. **Download** source vocab data and tools + +1. **Configure** your local database + +1. **Ingest** delta vocabulary files + +
+ +### Download +To create the Oncology Development Vocabulary, you must download the **[vocabTools](https://github.com/OHDSI/OncologyWG/tree/master/vocabTools)** and **[deltaVocab](https://github.com/OHDSI/OncologyWG/tree/master/deltaVocab)** folders from the OHDSI/OncologyWG repository. It may be simplest to clone the OHDSI/OncologyWG and work from there: + +`git clone https://github.com/OHDSI/OncologyWG.git` + +
+ +### Configure + +These methods assume you have the latest official release of the OMOP Vocabulary in *two identical schemas* in a Postgres database: +- **prod**: The **prod** schema contains the official ("production") OMOP Vocabulary. This vocabulary will not be changed but can be used to refresh the **dev** schema. +- **dev**: The **dev** schema begins as an exact copy of the official OMOP Vocabulary, but will be transformed into the Oncology Development Vocabulary using the deltaVocab files and the scripts in vocabTools. + +To enable the scripts in vocabTools, enter your database connection details into the **config.txt** file. + +
+ +### Ingest + +Create two folders in the vocabTools folder: concept and concept_relationship. + +Move the deltaConcept and deltaConceptRelationship files to the new concept and concept_relationship folders, respectively. + +Run **updateConcept.bat** to implement the changes from deltaConcept to the dev schema in your database. + +Run **updateConceptRelationship.bat** to implement the changes from deltaConceptRelationship to the dev schema in your database. + +Run **updateConceptAncestor.bat** to rebuild concept_ancestor based on the new concept and concept_relationship tables in the dev schema. + +--- + +## Development + +Using the delta vocab and helper scripts, a developer with an official OMOP Vocabulary database can quickly create a full, working version of the OMOP Vocabulary with all proposed changes implemented, allowing for advanced testing and use of existing OHDSI tools with a development version of the vocabulary. + +> See README of the [vocabTools](https://github.com/OHDSI/OncologyWG/tree/master/vocabTools) directory for instructions for contributing to the Oncology Delta Vocabulary + +--- + +
+ +# **GitHub Project** + +A GitHub Project has been created and customized to enable collaborative and dynamic project management. Notably this project exists at the organization level, not the repository level, thus enabling extended functionality including issue triage across multiple repositories. + +> Orientation and Onramp: [GitHub Project Orientation](githubProject.html) +> +> GitHub Project: [Oncology Maturity Sprint](https://github.com/orgs/OHDSI/projects/13) + +--- + +
+ +# **RMarkdown (docs)** + +We leverage the RMarkdown R Package to create content in Rmd files and generate them as HTML. Through GitHub Pages, these HTML files can be easily deployed as a project website. There are several options varying in technical complexity to contribute to this documentation. + +> [See here](githubProject.html#Document) for more details + +--- + +
+ +# **Validation Framework** + +
+ +## Context + + - Support the automated execution of scripts that return a simple signal (stoplight) that indicates whether a necessary component of an OHDSI study can run without error on appropriate required data content. Signals comprehensively cover data availability, data quality, and analytic algorithms specified in an OHDSI study. + - Signal generation and display can be generated locally and, optionally, shared centrally in order to facilitate rapid unambiguous assessment of candidate site’s ability to participate in a study. + - A version of the same approach might be extended to a non-study-specific display of a prespecified set of requirements for formally defined “levels of readiness” for OHDSI oncology studies that use the OHDSI Oncology 2.0 infrastructure. + +
+ +--- + + + +## Details + +
+ +### Rationale +Provide a semi-automated and extensible framework for generating, visualizing, and sharing an assessment of an OMOP-shaped database’s adherence to the OHDSI Oncology Standard (tables, vocabulary) and the availabilty and types of oncology data it contains. + +
+ +### Approach +*Assessments* can be executed against an OMOP-shaped database to create a characterization and quality report. They are created using specificications. + +*Specifications* are JSON files that describe an assessment. They are composed by compiling analyses together with threshhold values. + +*Analyses* execute a query and return a row count or proportion describing the contents in the database. For example, analysis_id=1234 returns “the number of cancer diagnosis records derived from Tumor Registry source data”. + +*Threshholds* provide study specific context to the results of analyses. An analysis asks how many cancer diagnoses derived from tumor registry data are in the database. Using threshholds, an assessment author can give ranges for “bad”, “questionable”, and “good” analysis results as they pertain to their study. An example threshhold, which would be encoded as JSON, could express the sentiment “A database with 0-200 diagnoses from tumor registry data would be unfit for this study, 201-500 diagnoses may be suitable, and over 500 diagnoses will be more enough.” + +--- + +
+ +## Implementation + +The R package provides functionality for the four major processes involved in the framework: + + - Authoring an assessment specification + - Executing an assessment specification + - Generating assessment results + - Visualizing assessment results + +--- + +
+ +## Development + +> See README of the [validationScripts](https://github.com/OHDSI/OncologyWG/tree/master/validationScripts) directory for instructions for contributing to the Oncology Validation Framework + +--- + +
diff --git a/rmd/tooling.Rmd b/rmd/tooling.Rmd index f80987f..faaa702 100644 --- a/rmd/tooling.Rmd +++ b/rmd/tooling.Rmd @@ -54,74 +54,28 @@ This package identifies oncology regimens. Firstly, it identifies all patients w --- -# **Development & Testing** +# **Development**
-## Characterization and Validation +## Delta Vocabulary -
+Documentation: [Delta Vocabulary](strategy.html#Delta_Vocabulary) -### Purpose +Maintaining the change between the official OMOP Vocabulary release and the Oncology Development Vocabulary allows for rapid development of OHDSI Oncology studies that are untethered from the official OMOP Vocabulary release cadence. By preserving only the changed elements, instead of the entire Oncology Development Vocabulary, this method provides a lightweight, GitHub-friendly solution, that is also respectful of (by way of avoiding) the licensed vocabulary terms. -Provide a semi-automated and extensible framework for generating, visualizing, and sharing an assessment of an OMOP-shaped database's adherence to the OHDSI Oncology Standard (tables, vocabulary) and the availabilty and types of oncology data it contains. - -### Overview - -The star of the framework is an R Package. Along with cataloguing an extensible set of queries and analyses used for assessing OMOP-shaped oncology data, the R package provides functionality for the four major processes involved in the framework: - -1) Authoring an assessment specification -2) Executing an assessment specification -3) Generating assessment results -4) Visualizing assessment results - -### Approach - -_Assessments_ can be executed against an OMOP-shaped database to create a characterization and quality report. They are created using specificications. - -_Specifications_ are JSON files that describe an assessment. They are composed by compiling analyses together with threshhold values. - -_Analyses_ execute a query and return a row count or proportion describing the contents in the database. For example, analysis_id=1234 returns "the number of cancer diagnosis records derived from Tumor Registry source data". - -_Threshholds_ provide study specific context to the results of analyses. An analysis asks how many cancer diagnoses derived from tumor registry data are in the database. Using threshholds, an assessment author can give ranges for "bad", "questionable", and "good" analysis results as they pertain to their study. An example threshhold, which would be encoded as JSON, could express the sentiment "A database with 0-200 diagnoses from tumor registry data would be unfit for this study, 201-500 diagnoses may be suitable, and over 500 diagnoses will be more enough." - -### Extensibility - -This tool is a product of collaboration. See the validation scripts README for detailed instructions on creating analyses (TODO) and using the R package to author and execute assessment specifications (TODO). -
- -
--- -## Delta Vocabulary Framework - -A suite of tools to quickly set up an environment for: -1) making local edits to the OMOP Vocabularies (concept and concept_relationship tables) -2) generating derived tables (concept_ancestor) -3) validating the vocabulary changes -4) outputting the table delta in a sharable format +# **Data Quality and Characterization**
-### Structure/Approach - -Git and GitHub offer a collaborative environment for proposing, discussing, and implementing changes to a reference vocabulary such as the OMOP Vocabulary. - -However, due to licensing and volume issues, it is not possible to maintain and develop the entire OMOP vocabulary in a GitHub repository as flat files. +## Adoption Validation Framework -To work around this, a group of collaborators can maintain and contribute to a growing list of edits to the OMOP Vocabulary. We call this list of edits the "delta vocab". +Documentation: [Validation Framework](strategy.html#Validation_Framework) -The delta vocab, which is literally a collection of concept and concept_relationship records exactly as they would represented in the OMOP Vocabulary table, provides a lightweight representation of any deviations from the official OMOP Vocabulary. +A semi-automated and extensible framework for generating, visualizing, and sharing database characterization and adherence to the OHDSI Oncology Standard Conventions. -Using the delta vocab and delta helper scripts, a developer with an official OMOP Vocabulary database can quickly create a full, working version of the OMOP Vocabulary with all proposed changes implemented, allowing for advanced testing and use of existing OHDSI tools with a development version of the vocabulary. - -The simplicity of maintaining as little of the vocabulary as possible and using scripted logic to apply changes to the existing vocabulary makes this method easy to implement, but also limited in its capabilities. As of now, the primary use for the delta vocab method is for *destandardizing and mapping non-standard terms*. - -For details on using the delta vocab and the helper scripts, see the README and function reference (TODO) - - -
---- \ No newline at end of file