fix: preserve Coding answers during profile-constrained extraction - #1101
rob-reynolds wants to merge 4 commits into
Conversation
Convert Coding to CodeableConcept only when the assignment parent matches an unsliced, single-type resource profile element. Preserve metadata and repeated-property cardinality. Real extraction-entry and Extension slice regressions prevent borrowing root or sibling type constraints. Unsupported nested/multi-type conversions and diagnostics remain unchanged. Validate across DSTU3, R4 and R5.
|
Formatting check succeeded! |
| if (answerType != null && !answerValue.fhirType().equals(answerType)) { | ||
| var newAnswerValue = | ||
| request.getAdapterFactory().createBase(newBaseForVersion(answerType, request.getFhirVersion())); | ||
| newAnswerValue.setValue(VALUE_PATH, answerValue); |
There was a problem hiding this comment.
The root cause of the defect occurs on this line. Fortunately, the else branch here already routes through transformValueToResource, which is identity for non-Coding. Making the first branch do the same looks like it'd fix this at the root, cover nested value[x] targets, and let the new setAnswerValue guard drop out. Is there a reason you preferred the call-site guard?
Something like this should work (for reference):
if (answerType != null && !answerValue.fhirType().equals(answerType)) {
var converted = transformValueToResource(request.getFhirVersion(), answerValue);
if (converted.fhirType().equals(answerType)) {
answerValue = converted; // Coding->CodeableConcept: now matches
} else {
var newAnswerValue = createBase(newBaseForVersion(answerType, ...));
newAnswerValue.setValue(VALUE_PATH, answerValue); // unchanged fallback + diagnostics
answerValue = newAnswerValue.get();
}
}There was a problem hiding this comment.
Ok, thanks for running the suggestion and relaying the results! Agreed that the actual "root fix" is reliable target-type resolution for nested/extension/slice contexts, not just relocating the call. Can we create a ticket for that?
barhodes
left a comment
barhodes
left a comment
There was a problem hiding this comment.
Would like to look at adding this into the definition based population branch to avoid merge conflicts down the road.
|
|
Superseded by #1108, which targets feature-definition-based-population. |
4 participants
When a QuestionnaireResponse contains a Coding answer and its extraction profile constrains an Observation value to CodeableConcept, extraction currently drops the answer. This can leave a subsequent PlanDefinition apply paused despite a supplied answer.
Convert Coding to CodeableConcept before assignment when the assignment parent matches the resource profile and the selected element is unsliced and has exactly one type. Preserve the complete Coding and repeated-property cardinality. Nested Extension and sibling-type-slice regressions prevent borrowing an unrelated profile constraint. Existing unsupported conversions and their diagnostic behavior remain unchanged.
Validation
This PR contains only the Coding change. Generated IDs are in a separate stacked PR. The tested v4.7.0 backport is available on codex/qr-extraction-backport; upstream currently has no 4.7 maintenance branch to target. No installed runtime or release was replaced.