zib-DAS #448
zib-DAS #448
Conversation
…n some sensible way
Plus several metadata fixes
pieter-edelman-nictiz
force-pushed
the
zib-DAS
branch
from
b884685 to
6dea9e8
Compare
pieter-edelman-nictiz
force-pushed
the
zib-DAS
branch
from
24fd558 to
50cbfc4
Compare
# Conflicts: # util/downloadTerminology/downloadTerminology.xsl
| </mapping> | ||
| </element> | ||
| <element id="Observation.code"> | ||
| <path value="Observation.code" /> |
There was a problem hiding this comment.
Shouldn't we put SNOMED 443349002 here, and map DASMethod on .method instead? Compare with zib PainScore.
There was a problem hiding this comment.
Fun fact: the last two codes in DASMethodeCodelist are children of 443349002, but the first two aren't. This could have been a double Coding in Observation.code, but alas.
None of the codes are an "observable entity" or "evaluation procedure"; they all fall under "assesment scale". So what to do ... I think they are not a method but define the scale itself (for PainScore this is basically unknowable as these are custom codes). So I think it would be better to have this on Observation.code and not on .method.
But maybe we should doublecheck with terminology first.
| </coding> | ||
| </patternCodeableConcept> | ||
| </element> | ||
| <element id="Observation.component:vasGeneralHealth.value[x]"> |
There was a problem hiding this comment.
Is this really a valid .component of the DAS? Strictly speaking, this is its own instance of the zib PainScore (with PainMeasuringMethod = 'VAS100'). Moreover, the description states this is related to the 'general health', hence it seems broader than the DAS.
There was a problem hiding this comment.
Maybe use the workflow-supportingInfo extension to a separate Observation, since .derivedFrom and .hasMember do not seem correct as well?
There was a problem hiding this comment.
The VAS here doesn't refer to a pain score, it's "a" visual analog scale about general health. On the zib level, it is just an integer. You could argue that this would be a distinct hasMember Observation in FHIR, but it wouldn't be an instance of zib Painscore. You'd also need a better definition code I think (but maybe that's true anyway).
There was a problem hiding this comment.
Ah you're right, I'm conditioned to always link VAS to PainScore... ;)
Still I'm not that fond of the mapping on .component (or .hasMember), as the concept is about general health. On the other hand I agree that the definition code is too generic to be used on a separate Observation. Maybe just keep it as-is in that case.
There was a problem hiding this comment.
I think it's best to go back to the zib centre for clarification first.
|
Opened three zib tickets regarding your feedback, I'll put further profiling on hold. |
No description provided.