Closed mmcdermott closed 3 months ago
I don't think that's quite right, as parent_codes should, and will, contain non-OMOP concepts to handle dataset specific ontology structures.
parent_codes must be a list of strings, each string being a higher level code that represents a generalization of the provided code. Parent codes can use any structure, but is recommended that they reference OMOP concepts whenever possible, to enable use of more generic labeling functions and OHDSI tools. OMOP concepts are referenced in these strings via the format "$VOCABULARY_NAME/$CONCEPT_NAME". For example: "ICD9CM/487.0"
Can you suggest some updated language @EthanSteinberg? I want to make sure it is accurately described.
What's wrong with the language I posted above in my original reply?
I apologize -- I didn't realize you had modified the quoted text, I thought you were just commenting on that block specifically in your reply. That text looks great. Thank you!
https://github.com/Medical-Event-Data-Standard/meds/blob/5f87c2fdcce7f8bab46af6f81ef7892fdee098c1/src/meds/schema.py#L134
@EthanSteinberg is the following language accurate for their constraints?
parent_codes
must be a list of strings, each string being a parent code in the OMOP concept space corresponding to this code. Here, a "parent" means that this code must be a realization of either the referenced OMOP concept or a more specific example of said concept. OMOP concepts are referenced in these strings via the format"$VOCABULARY_NAME/$CONCEPT_NAME"
. For example:"ICD9CM/487.0"