Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2.0 docs update #186

Merged
merged 8 commits into from
Feb 28, 2024
Merged

v2.0 docs update #186

merged 8 commits into from
Feb 28, 2024

Conversation

dogversioning
Copy link
Contributor

This PR adds documentation around some V2 features, and a generator for creating markdown tables.

Checklist

  • Consider if documentation (like in docs/) needs to be updated
  • Consider if tests should be added
  • Update template repo if there are changes to study configuration

@dogversioning dogversioning force-pushed the mg/2.0_docs_update branch 5 times, most recently from 1e357f9 to 12832b5 Compare February 27, 2024 19:15
@@ -52,15 +51,12 @@ SELECT
id,
category_code,
category_code_system,
component,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the fields removed here were not flattened - i'll swing back around on the required/must support fields on these.

@dogversioning dogversioning marked this pull request as ready for review February 27, 2024 20:13
cumulus_library/cli.py Show resolved Hide resolved
cumulus_library/template_sql/column_datatype.sql.jinja Outdated Show resolved Hide resolved
docs/creating-sql-with-python.md Outdated Show resolved Hide resolved
docs/creating-sql-with-python.md Outdated Show resolved Hide resolved
docs/creating-studies.md Outdated Show resolved Hide resolved
cumulus_library/study_parser.py Outdated Show resolved Hide resolved
docs/core-study-details.md Outdated Show resolved Hide resolved
docs/core-study-details.md Outdated Show resolved Hide resolved
cumulus_library/template_sql/column_datatype.sql.jinja Outdated Show resolved Hide resolved
Comment on lines +134 to +162
__Important detail on FHIR arrays__: When we flatten a FHIR element that
is specified as being potentially an array (like many instances of
CodeableConcept, for example), we create a seperate table from that
field. It can be joined back to the table it was extracted from by the
id field present in both tables.

However - in your study design, you will need to handle cases where
multiple items may exist in these tables. It is common for multiple
code systems to be used for a single record.

As an example, the Condition resource has a base level CodeableConcept
that _should_ contain a SNOMED code, but often has only an ICD9/10 code,
or a EHR vendor specific code. We handle this case in two ways:
- The __core__condition_codable_concepts_display__ table contains one
record per resource, where we specify a priority order and take the
first valid code we find, which is ok for cases where you aren't
very concerned about a specific coding and are just looking to get
an idea of what data you have
- The __core__condition_codable_concepts_all__ table contains
every code for every system found. This is useful when you are specifically
looking for data associated with a given clinical coding system, but
if you are not careful, you can cause a condition to be counted twice
by not specifying a coding system when joining this table with the
base condition table.

Your approach to handling this is going to be dictated by the specific
clinical context you're working with. In cases where we don't specify
two table types for an array resource, you should assume that we are
following the second pattern and account for that in your queries.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explicitly calling out this large text block i just added about the denormalized tables.

Comment on lines +56 to +60
To document your study strucuture, you can use the `generate-md` command
to create markdown tables you can copy into your study docs. Note that,
as of this writing, you'll need to supply a description for each field by
hand. This output will be generated inside your study, in a file named
`{study name}_generated.md`.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also calling out the 'you need to define your own description, for now'

@dogversioning dogversioning merged commit 53b5948 into main Feb 28, 2024
3 checks passed
@dogversioning dogversioning deleted the mg/2.0_docs_update branch February 28, 2024 16:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants