Stream: shorthand
Topic: SUSHI 2.0.0
Julian Carter (Aug 10 2021 at 18:59):
Introducing SUSHI 2.0.0! This release marks the end of the 2.0.0 beta phase; fully supporting the FHIR Shorthand v1.2.0 spec and introducing several new features, bug fixes, and breaking changes.
This release includes the following major features:
- Rule indentation for succinct specification of subpaths
- Logical models and custom resources
- Hierarchical CodeSystems and concept-specific caret rules
- Option to output preprocessed FSH
- Extensions for representing elements from other versions of FHIR
- Extension for profiling BackboneElements
- Insert rules with paths
- Specifying warnings to ignore during processing
- Support for mapping rules within rulesets
This release also includes the following breaking changes:
- Indent rules make whitespace before * significant.
- Support for deprecated syntax has been removed (the Mixins keyword, units keyword, as well as , and | separators)
- Support for limited ValueSet expansion has been removed
- Support for deprecated pre-SUSHI 1.0 project structures has been removed
To install or update to this new version, run the following command:
$ npm install -g fsh-sushi
See the SUSHI 2.0.0 Release Notes for more information.
Jean Duteau (Aug 10 2021 at 19:07):
Fantastic work by the SUSHI and FSH team! I do have a question/concern and it mostly relates to the integration of SUSHI with the CI IG publisher build framework. I'm unsure how the build gets the SUSHI, but I thought that did a npm install from scratch each time. That would appear to me that the CI builds will be using SUSHI 2.0.0? If that's true, then some of the breaking changes might affect our guides. I don't see any of the breaking changes affecting me but I'm raising this in case others might need to know.
Julian Carter (Aug 10 2021 at 19:13):
Yes, the IG Publisher will now use SUSHI 2.0.0 by default. This can be prevented by placing a fsh.ini file in the root directory of your project and placing the following in that file:
[FSH]
sushi-version=[insert previous version number here]
This will force the IG Publisher to use whatever version of SUSHI that you specified!
Chris Moesel (Aug 17 2021 at 17:23):
Also, the FSH team did regression tests against all FSH repos it could find (in GitHub/HL7 and all IGs registered w/ the autobuild system) -- and then submitted GitHub issues against every project that had a regression due to breaking changes in SUSHI 2.0.0. We did this many weeks ago, so hopefully this does not come as a surprise to anyone.
Patrick Werner (Aug 18 2021 at 14:10):
Hi, one question. Where is the documentation for the fsh.ini? Couldn't find it.
We have an IG with very large CodeSystems, timing out exectly after 5 minutes in the IG builder.
Patrick Werner (Aug 18 2021 at 14:10):
I found a thread Grahame mentioning increasing timout time for the builder in fsh.ini
Patrick Werner (Aug 18 2021 at 14:11):
But no information on how to do this..
David Pyke (Aug 18 2021 at 14:12):
[FSH]
timeout=600
David Pyke (Aug 18 2021 at 14:12):
That's in seconds
Patrick Werner (Aug 18 2021 at 14:14):
Thanks David! Is this documented somewhere?
David Pyke (Aug 18 2021 at 14:17):
Not that I'm aware of. @Chris Moesel ?
David Pyke (Aug 18 2021 at 14:19):
Wait, I'm wrong, It's here: https://fshschool.org/docs/sushi/running/ in a Tip box.
David Pyke (Aug 18 2021 at 14:19):
Might be worth adding to the "Configuration" page
Chris Moesel (Aug 18 2021 at 14:25):
Since this is an implementation detail, the fsh.ini file is not documented in the FSH spec itself, but it is documented in a Tip in the SUSHI documentation on FSH School here: https://fshschool.org/docs/sushi/running/#running-the-ig-publisher
Chris Moesel (Aug 18 2021 at 14:25):
Whoops. Was replying based on a notification and didn't notice that @David Pyke had already found it. Thanks, David!
Patrick Werner (Aug 18 2021 at 14:28):
Thanks @David Pyke @Chris Moesel
Google was not able to find this for some reason.
Greg Hunt (Aug 18 2021 at 17:52):
Are there any good examples of a Mapping with FHIR Shorthand
Greg Hunt (Aug 18 2021 at 17:56):
I am looking to setup mapping with a legacy file format and want to show the field level mapping in the IG, but I am getting hung up on setting up the Mapping
Chris Moesel (Aug 18 2021 at 19:23):
@Greg Hunt - I'm not aware of any good examples aside from the one simple example in the spec here: http://build.fhir.org/ig/HL7/fhir-shorthand/reference.html#defining-mappings
You could look at other IGs that declare mappings to see how they used mappings -- but unfortunately it is often obscured. I don't think that the IG Publisher renders the mappings (at least it doesn't seem that it has for US Core) -- so at that point you're having to look in the StructureDefinition JSON or XML source to see the mappings. Which is also something to consider since you said that you "want to show the field level mapping in the IG". As far as I know, if you want that to be surfaced in the user-facing documentation, you might have to manually author your own pages w/ that information. @Lloyd McKenzie -- is there any way to programmatically render SD mappings in an IG?
There is also StructureMap but that is an entirely different beast.
Grahame Grieve (Aug 18 2021 at 21:21):
if they're not being shown, that's because the template isn't including them. The fragments include the mappings
Lloyd McKenzie (Aug 18 2021 at 22:02):
The template includes a mappings tab. I'm seeing them, for example here: file:///C:/Users/lloyd/Documents/SVN/_IGs/sdc/output/StructureDefinition-sdc-questionnaire-mappings.html
Lloyd McKenzie (Aug 18 2021 at 22:04):
I think there's a mechanism to turn off some of the mapping sources if you don't want, but it's possible I'm remembering a proposed rather than implemented requirement. However, if you're using the default template, all mappings including those inherited from the base spec should show up.
Chris Moesel (Aug 19 2021 at 12:14):
Awesome. I looked at US Core 4.0.0 because I knew they had argonaut mappings in their SDs -- but there weren't any rendered mappings in the IG that I could find. I guess they must have used a different template or turned them off. Thank you for correcting and clarifying.
Elliot Silver (Aug 26 2021 at 01:41):
For "concept-specific caret rules", how can I distinguish properties for two concepts with the same code value, but different systems? It looks like caret-path rules are only differentiated by code value.
Chris Moesel (Aug 26 2021 at 12:39):
@Elliot Silver - concept-specific caret rules only apply to CodeSystem definitions. So... all of the codes in any given CodeSystem definition are always from a single system. If I've misunderstood your question, could you rephrase it?
Elliot Silver (Aug 26 2021 at 14:31):
Nope, you got it, I missed that part and thought it applied to valuesets.
Last updated: Apr 12 2022 at 19:14 UTC
