Stream: shorthand
Topic: shorthand & TestScript instances
Ardon Toonstra (Mar 26 2020 at 10:36):
Hi all!
We are investigating the use of shorthand for the creation of (many) TestScript instances. Every TestScript has specific information and a lot of duplicate info such as a set of asserts. Instead of copying this into every TestScript we want to inherit this information.
Our current approach based on paragraph 3.4.5. of the IG, is to create StructureDefinitions that specify a batch of asserts using fixed values. (see the Forge PrinstScrint below for our test profile)
Creating an instance using shorthand based on this profile, as shown in this snippet, doesn’t result in adding the asserts to the instance. It adds the fixed values of the .url, .name ect., but it doesn’t go into the .test.action. Nor does it when we specify .test.name in shorthand.
Are we doing something wrong? Would this be a good approach? Any suggestions? Testscript-profile.png
Nick Freiter (Mar 26 2020 at 12:14):
I am guessing what is happening here is that SUSHI is not being aggressive enough in which values are getting fixed. When you specify .test.name SUSHI should won't dig down into a fixed value like .test.action.assert.description, because .test.action is an array and we don't necessarily know how many elements are in that array. Now, I think SUSHI should be smart enough to recognize that the array is sliced with 1..1 elements, and automatically add those elements, but that is not something that has yet been implemented. I've made an issue on our GitHub to track this feature: https://github.com/FHIR/sushi/issues/300.
We are adding a new feature in our next release called RuleSet(http://build.fhir.org/ig/HL7/fhir-shorthand/reference.html#defining-rule-sets) which could provide a more quickly available solution to your problem. A RuleSet acts as a reusable chunk of rules, so if all your instances needed a certain set of rules applied, it may be easier to define that set of rules once using a RuleSet, and apply that RuleSet to each Instance.
Ardon Toonstra (Mar 26 2020 at 12:37):
Thanks for your comprehensive answer!
I believe you are right, the RuleSet is more in the direction of our use case. I will certainly try that one out once it is released. Do you have an estimated date for the next release?
Ardon Toonstra (Mar 26 2020 at 12:39):
Just a check: mixins of two RuleSet that both say something about Testscripts.test.action.asserts be added next to each other? So they don't overwrite each other?
Nick Freiter (Mar 26 2020 at 13:11):
We hope to have the release by the end of this week, but it would be early next week at the latest.
Well if two RuleSets both changed the exact same value, like if they both specified the value of .test[0].action[0].assert.description, then the whichever RuleSet was applied second would overwrite whichever RuleSet was applied first. But assuming the RuleSets are touching different values within an element, then yes two RuleSets can touch the same element alongside each other.
Last updated: Apr 12 2022 at 19:14 UTC
