[ ] paths to "neighborhoods" or roots in the document where appropriate data can be found
[ ] a description of the fields found there, what fields in the OMOP condition_occurrence table they will map too and what transformations are needed. Transformations basically means if you would use a HASH, DERIVED, FIELD or other config type. In English, how does what you find in CCDA need to be modified to fit into OMOP, if at all.
[ ] a description of linking issues. Is this something as simple as a "parse twice" PK-FK thing, or do we need to use the PK config type and link to more global resources. So for condition_occurrence specifically,
[ ] where does the person_id come from (likely the pk_dict and an FK config type)
[ ] where does the provider_id come from (FK, but might
[ ] where does the visit_occurrence_id come from (FK)
[ ] (I haven't seen a need or place for visit_detail_id yet)
Tips
There are questions here that may be hard to answer. Just seeing the questions is great progress.
This is an analysis ticket for starting work on the Problem List / conditions encounters ticket #106
Deliverables
Tips
There are questions here that may be hard to answer. Just seeing the questions is great progress.
Many clues to how ID linking works is in the Encounter Analysis
Reference
Mapping.py documentation may be useful as well.
OHDSI OMOP 5.4 CDM pages
`CREATE TABLE @cdmDatabaseSchema.condition_occurrence (