-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternative to JUTE $if derective proposal #2
Comments
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [{
"request": {
"url": "/Observation",
"method": "POST"
},
"resource": {
"code": {
"{% if QuestionnaireResponse.repeat(item).where(linkId='my-id') = '1' %}": {
"display": "Branch then"
},
"{% elsif QuestionnaireResponse.repeat(item).where(linkId='my-id').exists() = '2' %}": {
"display": "Branch two"
},
"{% else %}": {
"display": "Branch else"
}
}
}
}]
} |
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [{
"request": {
"url": "/Observation",
"method": "POST"
},
"resource": {
"code": {
"{% case QuestionnaireResponse.repeat(item).where(linkId='my-id') %}": {
"{% when '2' %}": { // '1' is a FHIRPath expression
"display": "Branch then"
},
"{% when '2' %}": { // '2' is a FHIRPath expression
"display": "Branch two"
},
"{% else %}": {
"display": "Branch else"
}
}
}
}
}]
} |
Ordering issue for multiple |
Check if it is possible to use an extension to implement if and/or case logic (Check #4 for more details). |
I added support for if and else, the examples are available in tests
If/else block should not contain user-defined keys because it's fully replaced with The condition must be a single element with true or false, otherwise, an exception will be triggered. I think it's more obvious behavior than just returning |
I've decided to adhere to fhirpath's iif behavior by using implicitly So, it works consistently with fhirpath conditions. |
It's not relevant for primitive types (str, number), because it might be expressed using FHIRpath
iif()
.For complex structures, I can suggest something like switch:
For implementation, it means if an object contains expression-keys and all of them are evaluated to boolean (array of one boolean element), then it should be handled as the switch.
It differs from #1, because all expressions must return booleans. Of course, there's an edge case, when #1 should map array of booleans, but it's not the case of usage.
The text was updated successfully, but these errors were encountered: