feat(hts): emit multi-issue OperationOutcomes from $validate-code#98
Merged
Merged
Conversation
The HL7 tx-ecosystem IG fixtures expect $validate-code failure cases to surface one OperationOutcome.issue per concern (abstract + not-in-vs, unknown-system + not-in-vs, inactive + valid-but-not-active + not-in-vs, display-mismatch, etc.) rather than collapsing every signal into a single error issue. The previous implementation always emitted a single issue with code=code-invalid + tx-issue-type=not-in-vs, which made ~40 fixtures fail with "Expected:N Actual:1" issue counts. Changes: - types.rs: add ValidationIssue (severity, fhir_code, tx_code, text, location, message_id) and ValidateCodeResponse.issues field — backends push one issue per detected concern; the operations layer renders them as OperationOutcome.issue[] entries and joins their texts (alphabetically, "; "-separated) into the top-level message parameter. - backends/sqlite/value_set.rs::finish_validate_code_response: emit separate issues for code-not-in-vs, abstract (business-rule code-rule + code-invalid not-in-vs), inactive (warning), display-mismatch (error invalid-display), and the IG-specific "valid but not active" triple when a code is in the underlying CodeSystem but excluded from the VS by activeOnly / compose.inactive=false. - backends/sqlite/code_system.rs: emit not-found/not-found for unknown CodeSystem, code-invalid/invalid-code for unknown code, and invalid/invalid-display for display mismatch. - operations/validate_code.rs::build_validate_response: walk resp.issues; synthesise an UNKNOWN_CODESYSTEM not-found issue when the operations layer sees an unknown system (surfaces the IG-required second issue alongside the backend's not-in-vs); fall back to the legacy single-issue path only when no structured issues are present. - backends/postgres/*: add empty issues field to satisfy the new struct shape (postgres backend keeps single-message behaviour for now). Adds two unit tests (vs_validate_unknown_system_emits_two_issues, vs_validate_no_system_on_coding_emits_invalid_data_issue) covering the two simplest multi-issue scenarios. All 622 helios-hts tests pass. [skip ci]
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The HL7 tx-ecosystem IG fixtures expect $validate-code failure cases to surface one OperationOutcome.issue per concern (abstract + not-in-vs, unknown-system + not-in-vs, inactive + valid-but-not-active + not-in-vs, display-mismatch, etc.) rather than collapsing every signal into a single error issue. The previous implementation always emitted a single issue with code=code-invalid + tx-issue-type=not-in-vs, which made ~40 fixtures fail with "Expected:N Actual:1" issue counts.
Changes:
Adds two unit tests (vs_validate_unknown_system_emits_two_issues, vs_validate_no_system_on_coding_emits_invalid_data_issue) covering the two simplest multi-issue scenarios. All 622 helios-hts tests pass.
[skip ci]