FHIR Chat · Announcing SUSHI 0.9.0 · shorthand

Stream: shorthand

Topic: Announcing SUSHI 0.9.0

---

Chris Moesel (Feb 17 2020 at 22:14):

Announcing SUSHI 0.9.0 with the following features, enhancements, changes, and bug fixes:

• Exports results into type-specific folders
• Generates StructureDefinitions without snapshot elements by default (#186)
• Automatically applies value[x] 0..0 to complex extensions and extension 0..0 to simple extensions (#183)
• Adds support for code system URLs containing # by allowing authors to escape # (#180)
• Fixes differential bug that didn't include slice names in sparse slice differentials (#204)
• Checks to ensure that fixed values aren't already fixed by a parent pattern (#84)
• Adds support for Description: keyword on Instances (descriptions are reflected in rendered IG pages)
• Allows authors to add extensions to instances even when the profile doesn't explicitly specify them (#188)
• Reports errors when instances do not provide required (1..1) values (#206)
• Allows authors to provide their own files in ig-data/input/includes (including menu.xml)
• Allows authors to force pages to be listed in a certain order by prefixing page names with a number and underscore
• Changes the default index page title to: Home
• Uses the ig.ini properties copyrightyear and ballotstatus to populate the ImplementationGuide.definition.parameter values for copyrightyear and releaselabel
• Exits with a non-success code when there are errors (useful for CI)

See release notes for further details: https://github.com/FHIR/sushi/releases/tag/v0.9.0

David Hay (Feb 17 2020 at 22:23):

Glad that I can still generate a snapshot when needed!

David Hay (Feb 17 2020 at 22:24):

Multiple input folders is still on the roadmap tho?

Chris Moesel (Feb 18 2020 at 13:40):

Multiple input folders is still on the roadmap tho?

I expect we'll think more about that as we work on next steps for IG generation. The templating framework only allows certain folders as input to the publisher -- so there isn't a lot we can do there. Are you mainly looking for the ability to structure your FSH how you want, even if it all ends up in a different layout when we generate the FHIR definitions?

David Hay (Feb 18 2020 at 23:01):

More the input (.fsh) files. I have examples, profiles and extensions in the same folder - would be kinda nice to separate them even if they all need to be i the same output folder (input to IG builder)

Pétur Valdimarsson (Feb 19 2020 at 07:50):

I ran into the same issue with the input folder. My input directory was getting too crowded to be readable. Submitted a PR, but probably did it in the wrong order. Should have added an Issue first. Best do that to see if there is interest for this. (edited for clarification)

Jose Costa Teixeira (Feb 19 2020 at 08:03):

they do not need to be in the same output folder.

Jose Costa Teixeira (Feb 19 2020 at 08:04):

1. the base IG template supports
   a) just a "resources" folder
   b) all these folders
   pasted image
   

Jose Costa Teixeira (Feb 19 2020 at 08:05):

and this is actually something that we can configure even as an IG parameter

Jose Costa Teixeira (Feb 19 2020 at 08:10):

this is my folder structure,
pasted image

Jose Costa Teixeira (Feb 19 2020 at 08:10):

I think it makes sense to structure fsh folders in the same way

Pétur Valdimarsson (Feb 19 2020 at 08:18):

Jose Costa Teixeira said:

I think it makes sense to structure fsh folders in the same way

I'm not quite sure since FSH allows for quite a variation of ways to work. People may want to group all things related to a resource (extensions, valuesets ...) in the same .fsh file and structure the files in documents by other criterias than resource type.

Jose Costa Teixeira (Feb 19 2020 at 08:46):

My remarks is for having a consistent folder structure - in that case, i'd use the IG folder structure which is more than the single "resources" folder.
Or we can override it. I just didn't want Chris to feel limited by the template

Jose Costa Teixeira (Feb 19 2020 at 08:48):

For example, I wanted to structure my resources by project - Core profiles, Region 1, Region 2, Project X, Project Y... But when I normalize the folder structure, I use the standard IG folders.

Jose Costa Teixeira (Feb 19 2020 at 08:49):

in any case, this was the point

The templating framework only allows certain folders as input to the publisher -- so there isn't a lot we can do there

There is a few things we can do there even without changing the template which is not that hard and could be done in sushi even - that would be cool

Chris Moesel (Feb 19 2020 at 15:14):

I was basing my thoughts on this bit of the IG Publisher Using Templates documentation:
pasted image

Chris Moesel (Feb 19 2020 at 15:16):

@Jose Costa Teixeira -- are you saying that this list of folders is not "closed" -- but can be expanded? If so, then that certainly is something we could consider taking advantage of if people find it helpful.

Jose Costa Teixeira (Feb 19 2020 at 15:20):

can you point me to a working sushi-based IG?

Chris Moesel (Feb 19 2020 at 15:20):

i'd use the IG folder structure which is more than the single "resources" folder

Note that in SUSHI 0.9.0, we moved away from the single "resources" folder and now output to "profiles", "extensions", "vocabulary", and "examples". But that's still hard-coded into SUSHI, not configurable or affected by the input file structure.

As @Pétur Valdimarsson suggested, we anticipate that people may group things by like concepts (e.g., putting a Diabetes profile in the same file as its corresponding value set and related extensions) -- so we want to ensure we continue to support a structure like that in the FSHTank.

Jose Costa Teixeira (Feb 19 2020 at 15:21):

actually, the list you have is valid. "my" list also included the folders for the pages

Chris Moesel (Feb 19 2020 at 15:21):

@Jose Costa Teixeira -- mCODE is built using SUSHI now. Here is the FSHTank source for it: https://github.com/standardhealth/fsh-mcode

Jose Costa Teixeira (Feb 19 2020 at 15:22):

ah ok, so the entire IG resource is generated by code...

Jose Costa Teixeira (Feb 19 2020 at 15:22):

right?

Chris Moesel (Feb 19 2020 at 15:22):

Yep.

Chris Moesel (Feb 19 2020 at 15:23):

And we're working on defining how to allow more control of that as well. Right now, there are some limits (you can't easily add custom parameters, etc) -- that's a known limitation we need to address.

Jose Costa Teixeira (Feb 19 2020 at 15:23):

can we move this to another stream?

---

Last updated: Apr 12 2022 at 19:14 UTC