Constrain query and view operation parameters to their profiles - #374
Merged
Conversation
Tighten the loosely-typed query- and view-bearing parameters across the four data operations so the machine-readable OperationDefinitions match their stated intent (issue #367). The query parameters (queryReference, queryResource in $sqlquery-run and $sqlquery-export) now carry a targetProfile of both the SQLQuery and SQLView profiles, with the inline parameters typed Library, and their documentation names both profiles. The view parameters (viewReference everywhere, and the inline viewResource in both export operations) now carry a targetProfile of ViewDefinition, with the inline parameters narrowed from Resource to CanonicalResource to match the existing $viewdefinition-run viewResource precedent. patient, group and source are left unchanged. This is a constraining change (constitution IV): the parameters move from unconstrained to profiled. Because the documentation always described a SQLQuery or SQLView Library or a ViewDefinition, and the guide is pre-publication (2.1.0-pre), no conforming caller is broken.
johngrimes
marked this pull request as ready for review
June 22, 2026 21:38
niquola
approved these changes
Jun 23, 2026
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
2 participants
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.
Resolves the loose typing reported in #367, plus the agreed consistency expansion across the matching view parameters. The query- and view-bearing parameters in the four data operations were typed too broadly, so the machine-readable
OperationDefinitions permitted a reference to, or an inline copy of, any resource where only a SQLQuery/SQLView or a ViewDefinition is meaningful.This constrains them in
input/fsh/operations.fsh:queryReference,queryResourcein$sqlquery-runand$sqlquery-export) gain atargetProfileof both the SQLQuery and SQLView profiles (any-of), the inline parameters are typedLibrary, and their documentation - along with the$sqlquery-exportqueryumbrella - now names both profiles rather than SQLQuery alone.viewReferenceacross the operations, and the inlineviewResourcein both export operations) gain atargetProfileof ViewDefinition, with the inline parameters narrowed fromResourcetoCanonicalResourceto match the existing$viewdefinition-runviewResourceprecedent.Closes #367.