SUSHI 2.10.1

What's Changed

• Allow versioned URL in extension contains rule (#1251) by @mint-thompson in #1255

To install or update, run:

npm install -g fsh-sushi

Full Changelog: v2.10.0...v2.10.1

SUSHI 2.10.0

What's Changed

• Automatically load hl7.fhir.uv.extensions for FHIR R5 by @cmoesel in #1236 and #1247 (details below)
• Support dependencies on specific CI build branches by @cmoesel in #1241 (details below)
• Improve import & export of ids/extensions on primitives by @cmoesel in #1249
• Update find-repos script, repos-all, and repos-select (development utility) by @cmoesel in #1235

Details

Automatically load hl7.fhir.uv.extensions for FHIR R5

The FHIR R5 core package no longer includes extensions. Instead, extensions are provided by the hl7.fhir.uv.extensions package. In order to provide a seamless and user-friendly experience, the latest released extensions package is loaded automatically for IGs based on R5. This follows the same behavior as the IG Publisher.

Support dependencies on specific CI build branches

If an author specifies a dependency package with the version current, then the latest package from the CI build server will be used. This functionality has existed in SUSHI for quite a while. In this release, authors may now specify CI builds of specific branches by using the version: current$branchname. For example, to get the CI build for a branch named my-test-branch, specify the dependency version as current$my-test-branch.

To install or update, run:

npm install -g fsh-sushi

Full Changelog: v2.9.0...v2.10.0

SUSHI 3.0.0 Beta 2

SUSHI 3.0.0 Beta 2 is the second beta release for SUSHI 3.0. The SUSHI 3.0 beta releases change SUSHI behavior and output. They also require a later version of Node.js. As such, SUSHI 3.0 is considered to have breaking changes.

SUSHI 3.0.0 Beta 2 Overview

SUSHI 3.0.0 Beta 2 introduces the following changes from the SUSHI 3.0.0 Beta 1 release:

• Changes to how you use SUSHI on the command line (#1163)
• New optional "manual slicing" mode for improved control over slice order (#1121, #1200) (breaking change if enabled)
• Do not set resource version unless specifically set by author (#1143) (breaking change)
• Default resource status to IG status instead of active (#1143) (breaking change)
• New fsh-link-references.md file for easier linking in pages (#1136)
• Support for scientific notation of numbers (#1203)
• Order IG resources based on the configuration order (#1118)
• New update-dependencies command (#1152)
• Configurable log levels (#1208)
• Include default type slicing in differential (#1179)
• All updates from SUSHI 2.6.1, 2.7.0, 2.7.1, 2.8.0, and 2.9.0

SUSHI 3.0.0 Beta 2 Details

Changes to how you use SUSHI on the command line

The sushi executable now takes a command as the second argument. Available commands are: build, init, update-dependencies, and help. This provides a more consistent approach to using SUSHI and allows for further functionality in the future.

• To build a project, use sushi build path/to/project (or sushi build to build the current directory).
• To initialize a new project, use sushi init.
• To update your dependencies to the latest versions, use sushi update-dependencies path/to/project (or sushi update-dependencies to update dependencies in the current directory). See New update-dependencies command below for more details.

For now, SUSHI will continue to accept the legacy usage for building, allowing for users to enter just sushi or sushi path/to/project. Future versions, however, may deprecate and/or remove legacy command support.

New optional "manual slicing" mode for improved control over slice order

When processing Instances in SUSHI 2.x, SUSHI always processes the slices according to the following rules:

• Required slices are added as the first elements in the sliced array.
• If an author adds optional slices using named slice paths, they are added after the required slices.
• If an author uses numeric index paths or soft index paths to reference slices, they may overwrite existing values and/or add new values.

This approach makes it difficult (or impossible) for authors to control the exact order of elements in a sliced array. In addition, it causes confusion when authors use soft indexing and mistakenly overwrite a required slice (partially or completely). That said, many authors have come to expect this behavior and have written their FSH to accommodate it. For this reason, SUSHI 3.0.0 continues to work this way by default (avoiding unexpected changes in existing IGs).

Going forward, however, FSH authors are encouraged to use the new instanceOptions --> manualSliceOrdering option in sushi-config.yaml. When set to true, this indicates that SUSHI should use the new manual slice ordering mode when processing instances. This new mode processes slices according to the following rules:

• Authors should always add slice values using named slice paths.
• Slice values are added to the array in the order they are referenced in the FSH Instance rules (while keeping items in the same slice contiguous).
• When values are added using a soft index path, the soft index takes into account preceding named slice paths, adding the item after them.
• Any remaining unreferenced required slices are added at the end.

Authors who enable manualSliceOrdering on existing projects should carefully review the results, as the new rules for slice application may result in unexpected output. To mitigate risk, authors should check all of their Instances to ensure they use named slice paths when assigning slice values in Instances.

To enable manual slice ordering add (or modify) the following in your sushi-config.yaml:

instanceOptions:
  manualSliceOrdering: true

NOTE: The FSH team recommends that new projects enable manualSliceOrdering. As such, the sushi init command will generate a sushi-config.yaml with manualSliceOrdering set to true.

For more information and examples, see Manual Slice Ordering on FSHSchool.

Do not set resource version unless specifically set by author

SUSHI 2.x automatically defaults the version field on Profiles, Extensions, Logical Models, Resources, Value Sets, and Code Systems to the version of the IG. SUSHI 3.0.0, however, no longer sets the version unless the author has specifically set it via a FSH rule. This allows the version to be controlled by the FHIR templates and IG Publisher. The default behavior for these is to apply the IG version across all resources, so most authors will not see a change in the end result.

Authors who want more control over when and how version is set should look into the apply-version and default-version IG parameters, which can be set in the sushi-config.yaml parameters object.

Default resource status to IG status instead of active

SUSHI 2.x automatically defaults the status field to active on Profiles, Extensions, Logical Models, Resources, Value Sets, and Code Systems. SUSHI 3.0.0, however, now defaults the status to be the same as the overall IG status. This aligns more closely to the behavior of the IG Publisher and more likely reflects the intended status of resources. Authors can always override the status on individual definitions via a caret rule (e.g., * ^status = #active).

New fsh-link-references.md file for easier linking in pages

SUSHI 3.0.0 now generates a file at fsh-generated/includes/fsh-link-references.md. This file makes linking to IG resources easier in IG markdown pages. To use it, add {% include fsh-link-references.md %} to the bottom of the markdown (.md) file where you want to link by resource names.

After doing that, you can reference IG resources in that markdown file using their name surround by square brackets. For example, if your FSH defines Profile: NationalPatient, then the following markdown will correctly link to that profile:

This IG defines a [NationalPatient] that represents...

...

{% include fsh-link-references.md %}

This feature is optional. Authors who do not wish to use it should not add the include directive in their markdown files.

For more information and examples, see Link References on FSHSchool.

Support for scientific notation of numbers

Authors can now assign numbers using scientific notation. For example:

* valueInteger = 2e8

Both positive and negative exponents are supported, but authors should take care to ensure that the resulting value is appropriate for the data type it is being assigned to.

Order IG resources based on the configuration order

SUSHI 3.0.0 preserves the order of resources when all resources are manually listed in sushi-config.yaml's resources section or groups sections. Otherwise SUSHI orders the resources by their title (when applicable) or id. This ordering affects the order in which resources are listed in the IG's generated table of contents.

New update-dependencies command

SUSHI 3.0.0 introduces a new update-dependencies command. When run, this command checks the dependencies defined in the sushi-config.yaml file to see if they are at the latest published versions. If SUSHI finds outdated dependencies, it will display a list of the outdated dependencies and ask the user if they wish to update. If the user chooses to update them, SUSHI will directly modify the sushi-config.yaml file with the latest versions and download them to the FHIR cache. Any dependency with a current or dev version will not be modified. This command can be used in the root folder of a project as follows:

sushi update-dependencies

Users can also specify a project path:

sushi update-dependencies path/to/project

For more information, see update-dependencies on FSHSchool.

Configurable log levels

While SUSHI 2.x allowed users to indicate if they wanted debug logging, SUSHI 3.0 allows users more control of the logging. Users can pass a -l or --log-level flag to specify the desired log-level: error, warn, info, or debug. For example, sushi build -l warn will run SUSHI in the current directory, outputting only warn and error messages.

Include default type slicing in differential

SUSHI 3.0.0 Beta 1 stopped using choice type renaming in eleme...

SUSHI 2.9.0

What's Changed

• Allow Logical Models and Resources to constrain inherited elements by @cmoesel in #1207
• Support IG R5 properties in R4 IGs by @jafeltra in #1189
• Automatically load hl7.terminology package by @cmoesel in #1205
• Find entities by id, even when their id is set by a rule by @mint-thompson in #1198
• Use inserted rules when checking new concepts by @mint-thompson in #1196
• Update uninherited extensions based on JIRA-28441 by @cmoesel in #1212
• Load dependencies in deterministic order by @cmoesel in #1213

Details

Allow Logical Models and Resources to constrain inherited elements

In prior versions of SUSHI, SUSHI prevented authors from constraining inherited elements in logical models and custom resources. Based on discussions with the FHIR team and clarifications in the specification, we have lifted this restriction. Authors can now constrain inherited elements in logical models and custom resources. Slicing, however, is still not allowed in either case.

Support IG R5 properties in R4 IGs

FHIR R5 added several new properties in the Implementation Guide resource. To support a consistent authoring experience, IG authors can reference these new properties in sushi-config.yaml for R5 IGs and R4 IGs. When used in R4 IGs, the property will be translated into the corresponding R4 property or an interversion extension. Authors should note, however, that in some cases the IG Publisher may not yet use these properties in an R4 context.

Automatically load hl7.terminology package

The hl7.terminology package (a.k.a. THO) defines Code Systems and Value Sets that are used by HL7 standards and implementation guides. Since these terminology definitions are considered a core aspect of standards and IGs, they are loaded by default. The IG Publisher already does this; now SUSHI does it as well. Normally, the latest release of hl7.terminology.r4 is loaded, but authors can override this by explicitly adding a hl7.terminology, hl7.terminology.r4, or hl7.terminology.r5 dependency (to a specific version) in their sushi-config.yaml file.

When this dependency is automatically added, failure to download it is considered only a warning and SUSHI proceeds as normal.

To install or update, run:

npm install -g fsh-sushi

Full Changelog: v2.8.0...v2.9.0

SUSHI 2.8.0

SUSHI 2.8.0 introduces minor enhancements and bug fixes.

What's Changed

• Automatically load hl7.fhir.uv.tools dependency by @mint-thompson in #1186
• Warn when ig.ini does not point to SUSHI-generated IG JSON by @cmoesel in #1193
• Keep parent's fixedUri on Extension.url of child extensions by @mint-thompson in #1182

Details

Automatically load hl7.fhir.uv.tools dependency

The FHIR Tooling Extensions IG (hl7.fhir.uv.tools) defines the extensions that may be useful in the development of implementation guides. For example, the Additional Binding Extension can be used to specify additional binding types on a coded element.

Since these extensions are considered a core aspect of IG tooling, the package that provides them is included by default. The IG Publisher already does this; now SUSHI does it as well. Normally, the latest build of hl7.fhir.uv.tools is included, but authors can override this by explicitly adding a hl7.fhir.uv.tools dependency (to a specific version) in their sushi-config.yaml file.

When this dependency is automatically added, failure to download it is considered only a warning and SUSHI proceeds as normal.

Full Changelog: v2.7.1...v2.8.0

SUSH 2.7.1

SUSHI 2.7.1 is a patch release containing several bug fixes and minor enhancements.

What's Changed

• Fix CodeSystem resolution for systems in external packages by @jafeltra in #1175
• Fix fishing for profiles with a version by @jafeltra in #1167
• Escape reserved characters in menu.xml by @jafeltra in #1153
• Avoid redefining inherited elements in logical models and resources by @guhanthuran in #1114
• Improve warning message related to naming rules by @guhanthuran in #1147
• Warn on empty titles and descriptions by @guhanthuran in #1158
• Update IG parameters links by @qligier in #1164

New Contributors

• @qligier made their first contribution in #1164

To install or update, run:

npm install -g fsh-sushi

Full Changelog: v2.7.0...v2.7.1

SUSHI 2.7.0

SUSHI 2.7.0 includes the following enhancements and bug fixes:

• Update to support the current R5 ballot version of the Implementation Guide resource (details below)
• Properly validate elements on Instances that are children of slices (#1089)
• No longer include Instances of custom resources in the ImplementationGuide JSON to support IG Publisher requirement (#1090)
• Correct the grammar in an error message (#1142) thank you to @vadi2 for contributing this fix!

NOTE: At the time of this release, the HL7 IG Publisher crashes when attempting to process R5 IGs. This is a known issue and is expected to be fixed soon. As a result, you will not be able to do a full build of an R5 IG until the HL7 IG Publisher is fixed.

FHIR R5 Ballot ImplementationGuide Support

In a recent update, the IG Publisher now requires that any Implementation Guide published with a FHIR R5 version include an ImplementationGuide resource that is compliant to the current resource definition. If an Implementation Guide still uses FHIR R4, the R4 version of the ImplementationGuide can and should be used, as documented on chat.fhir.org here.

Because SUSHI generates this resource and there are breaking changes in the new version, this release updates the ImplementationGuide resource SUSHI generates. The following changes were made:

• Support for the new ImplementationGuide.definition.page.name element, which replaces the R4 ImplementationGuide.definition.page.nameUrl.
• Support for setting the new ImplementationGuide.definition.page.source[x] directly in the sushi-config.yaml file using sourceString, sourceUrl, or sourceMarkdown on an entry in pages.
• Support for representing ImplementationGuide.definition.parameter.code as a Coding.
  • If a parameter key in sushi-config.yaml's parameters entry is in FSH code format (i.e., {system}#{code}), SUSHI will use the provided system and code as the ImplementationGuide.definition.parameter.code. For example, the following parameter could be specified:

    parameters:
        http://example.org/parameters#new-parameter: true

  • Otherwise, if the parameter key is in the GuideParameterCode system, SUSHI will set that system automatically.
  • Otherwise, SUSHI will set the system to http://hl7.org/fhir/tools/CodeSystem/ig-parameters, as documented on chat.fhir.org here.
• Support for the new ImplementationGuide.definition.resource.isExample and ImplementationGuide.definition.resource.profile elements, which replace the R4 exampleBoolean and exampleCanonical elements.
• Support for setting the new ImplementationGuide.definition.resource.isExample directly in the sushi-config.yaml file.
• Support for setting the new ImplementationGuide.definition.resource.profile directly in the sushi-config.yaml file.
• Support for setting the new ImplementationGuide.copyrightLabel directly in the sushi-config.yaml file.
• Support for setting the new ImplementationGuide.versionAlgorithm[x] directly in the sushi-config.yaml file using versionAlgorithmString or versionAlgorithmCoding.
• Support for setting the new ImplementationGuide.dependsOn.reason directly in the sushi-config.yaml file in an entry in dependencies.

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation and/or the FSH Specification.

Install or Update

To install or update to this release, run the following command:

$ npm install -g fsh-sushi

To revert to a previous release, run a command like the following:

$ npm install -g [email protected]

To check or confirm what version of SUSHI you have installed, you can run the following command:

$ sushi -v

SUSHI 3.0.0 Beta 1

SUSHI 3.0.0 Beta 1 is the first beta release for SUSHI 3.0. This release significantly changes SUSHI output in certain scenarios. It also requires a later version of Node.js. As such, this release is considered to have breaking changes.

SUSHI 3.0.0 Beta 1 Overview

SUSHI 3.0.0 Beta 1 introduces the following changes from the SUSHI 2.x releases:

• Require Node.js 16 or Node.js 18 (details below)
• Do not use choice type renaming in element ids or paths (#954) (details below)
• Do not slice choice elements when they have been restricted to a single type (#1088) (details below)
• Automatically assign title and description for Instances that support them (#1003) (details below)
• Use separate FHIR Package Loader library for handling dependencies (#1026)
• Update parser/lexer library to support more current versions of Node (#933)

NOTE: This is a beta release and may not be as stable as previous production releases. Additional beta releases with additional features and breaking changes are expected in the near future. Please be aware that functionality in this release is subject to change before the final release. We value user feedback, so please let us know your thoughts or concerns about this release.

SUSHI 3.0.0 Beta 1 Details

Require Node.js 16 or Node.js 18

Node.js 12 has reached its end-of-life and Node.js 14 is currently in its maintenance-only phase (see Node.js Releases). In order to ensure that SUSHI remains performant and secure, it now requires Node.js 16 (LTS) or 18 (Current). Although Node.js 12 (EOL) and 14 (Maintenance) currently work with this release of SUSHI, they are not officially supported (and may stop working in the future).

To download a more recent version of Node.js go to: https://nodejs.org/en/download/.

Do not use choice type renaming in element ids or paths

SUSHI 1.x and 2.x utilized an approach to choice types that simplified their element ids and paths. For example, Observation.value[x]:valueQuantity could be simplified to Observation.valueQuantity in the profile's differential and the IG Publisher would convert it to the "long form" during the snapshot generation process. This was referred to as choice type renaming.

While this was once considered an acceptable (and even recommended) approach, it is no longer considered good practice. In fact, in some cases this approach has caused problems in tooling and validation. As a result, SUSHI 3.0.0 no longer supports choice type renaming.

Consider the following rule on an Observation profile:

* valueQuantity MS

In SUSHI 2.x, this results in the following profile differential element:

{
  "id": "Observation.valueQuantity",
  "path": "Observation.valueQuantity",
  "min": 0,
  "max": "1",
  "type": [{ "code": "Quantity" }],
  "mustSupport": true
}

In SUSHI 3.0.0, this results in the following instead:

{
  "id": "Observation.value[x]:valueQuantity",
  "path": "Observation.value[x]",
  "sliceName": "valueQuantity",
  "min": 0,
  "max": "1",
  "type": [{ "code": "Quantity" }],
  "mustSupport": true
}

This provides a more consistent representation of choice type elements without changing their meaning.

Do not slice choice elements when they have been restricted to a single type

In SUSHI 2.x, whenever an author uses a type-specific path (such as valueCodeableConcept), it uses the standard type slicing mechanism to represent it. While this is necessary to distinguish types when there are multiple types to choose from, it is not necessary when a choice element has already been constrained to a single type.

For example, consider the following FSH definition:

Profile: MyObservation
Parent: Observation
* value[x] only CodeableConcept
* valueCodeableConcept from MyValueSet

Given the definition above, SUSHI 2.x will produce a differential that slices value[x] by type and introduces a specific choice type slice for valueCodeableConcept:

Given the same definition, SUSHI 3.0.0 will recognize that value[x] can only be a CodeableConcept and will simplify the differential by applying the constraint directly to value[x] instead of slicing it:

This maintains the intent of the profile while simplifying its representation by avoiding unnecessary slices when possible.

Note: If a choice element has already been sliced (i.e., by a parent profile), then SUSHI 3.0.0 will maintain consistency by using choice type slicing even if the choice element has already been reduced to a single type.

Automatically assign title and description for Instances that support them

To define conformance resources other than profiles, extensions, code systems, and value sets, authors must define an Instance of the resource. Although conformance resources often have a title and description, SUSHI 2.x requires authors to set those using assignment rules (e.g., * title = "My Operation Definition"), even when the author already specified a title using the Title: keyword.

In SUSHI 3.0.0, if an author specifies a Title: on an Instance, and that instance type supports a title element, SUSHI 3.0.0 will automatically assign the Title: keyword value to the instance's title element. Similarly, if an author specifies a Description: on an Instance, and that instance type supports a description element, SUSHI 3.0.0 will automatically assign the Description: keyword value to the instance's description element.

For example, consider the following FSH definition:

Instance: MyBlankConceptMap
InstanceOf: ConceptMap
Title: "My Blank ConceptMap"
Description: "A blank ConceptMap (for example purposes)."
Usage: #definition
* status = #draft

In SUSHI 2.x, the Title: and Description: values will be used for generating documentation in the IG, but the actual instance will not contain them:

{
  "resourceType": "ConceptMap",
  "id": "MyBlankConceptMap",
  "url": "http://example.org/ConceptMap/MyBlankConceptMap",
  "status": "draft"
}

In SUSHI 3.0.0, however, the Title: and Description: values will be automatically applied to the instance:

{
  "resourceType": "ConceptMap",
  "id": "MyBlankConceptMap",
  "url": "http://example.org/ConceptMap/MyBlankConceptMap",
  "title": "My Blank ConceptMap",
  "description": "A blank ConceptMap (for example purposes).",
  "status": "draft"
}

Install or Update

NPM only installs non-stable releases when a tag or version number is specified. To install or update to this beta version of SUSHI, run the following command:

$ npm install -g [email protected]

To revert to the most recent stable (non-beta) release, run the following command:

$ npm install -g fsh-sushi

To check or confirm what version of SUSHI you have installed, you can run the following command:

$ sushi -v

Using SUSHI 3.0.0 Beta 1 in the Auto Build

The autobuild environment uses the latest stable version of SUSHI. To force the IG Publisher to use SUSHI 3.0.0-beta.1 when building your project (such as in the autobuild environment), create a fsh.ini file at the root of your project with the following contents:

[FSH]
sushi-version=3.0.0-beta.1

SUSHI 2.6.1

SUSHI 2.6.1 includes the following enhancements and bug fixes:

• SUSHI now allows for cardinality changes to child elements of sliced elements if the new cardinality is compatible with the existing cardinalities on child elements of the parent's slices (#1120) (details below)
• Fixes a bug causing minified XHTML values to work improperly with Webpack 5 (#1113) many thanks to @alexgwalley for contributing this fix!
• SUSHI now honors the NPM_CONFIG_REGISTRY environment variable when checking for the most recent SUSHI version (#1082) many thanks to @bkaney for contributing this fix!

Allow cardinality constraints to be applied to connected elements
When constraining cardinality, previous versions of SUSHI would not allow cardinality rules if the element’s new cardinality is narrower than the cardinality on any equivalent child elements of the slices of the parent (e.g. foo.bar and foo:slice.bar). Now, if all equivalent child elements can safely have the new cardinality constraint applied to them, the cardinality constraint is applied. Likewise, if any equivalent child elements can not safely accept the new cardinality constraint, the cardinality constraint is not applied to the rule’s element or any equivalent child elements.

As an example, consider a case where foo[mySlice].bar currently has a cardinality of 1..5 foo.bar currently has a cardinality of 0..*, and a cardinality constraint is being applied to foo.bar:

• Constraining foo.bar to 0..4 is safe. The resulting cardinality on foo[mySlice].bar will be 1..4.
• Constraining foo.bar to 2..6 is safe. The resulting cardinality on foo[mySlice].bar will be 2..5.
• Constraining foo.bar to 0..10 is safe. The cardinality on foo[mySlice].bar will remain 1..5.
• Constraining foo.bar to 1..1 is safe. The resulting cardinality on foo[mySlice].bar will be 1..1.
• Constraining foo.bar to 6..8 is not safe. An error will be logged, and no cardinalities will change.

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation and/or the FSH Specification.

Install or Update

To install or update to this release, run the following command:

$ npm install -g fsh-sushi
To revert to a previous release, run a command like the following:

$ npm install -g [email protected]
To check or confirm what version of SUSHI you have installed, you can run the following command:

$ sushi -v

SUSHI 2.6.0

SUSHI 2.6.0 includes the following enhancements and bug fixes:

• Friendlier configuration properties (details below) (#1018, #1019)
• Add support for extensions on Implementation Guide pages that are configured in sushi-config.yaml (details below) (#1094)
• Allow SUSHI to run without any arguments (#1092)
• Canonical keyword is insensitive to definition order (#1073)
• Validate the values of complex types when assigning a value (#1108)
• Avoid assigning duplicate values on sliced elements (#1008)
• Fix incorrect error when constraining types on choice elements with semi-matching slice names (#1061)

Friendlier Configuration Properties

SUSHI now supports referring to resources by their name or id in the sushi-config.yaml file in various places. The resource name or id can be used directly in the following places:

• global profile values
• group resources
• resources
• resources' exampleCanonicals

For example, SUSHI use to require a configuration file to look like the following:

global:
  Patient: http://example.org/fhir/StructureDefinition/my-patient-profile
  Encounter: http://example.org/fhir/StructureDefinition/my-encounter-profile

resources:
  Patient/my-example-patient:
    name: My Example Patient
    description: An example Patient
    exampleBoolean: true

The following simpler and friendlier syntax is now supported and is equivalent to the configuration above:

global:
  Patient: MyPatientProfile
  Encounter: MyEncounterProfile

resources:
  my-example-patient:
    name: My Example Patient
    description: An example Patient
    exampleBoolean: true

For further examples, see #1018.

In addition, groups can now be defined without any resources. The following configuration format is now supported:

groups:
  GroupA:
    name: Group A
    description: My Group A
  GroupB:
    name: Group B
    description: My Group B

For more detailed examples of how to define groups, see #1019.

Extensions on Configured ImplementationGuide Pages

SUSHI supports configuring pages in the ImplementationGuide resource through the sushi-config.yaml file. Now, SUSHI supports adding extensions to the configured pages. The following configuration is now supported:

pages:
  index.md:
    title: Example Home
    extension:
      - url: http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status
        valueCode: trial-use

An extension array with the configured properties is added to the "Example Home" page entry in the ImplementationGuide.

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation and/or the FSH Specification.

Install or Update

To install or update to this release, run the following command:

$ npm install -g fsh-sushi

To revert to a previous release, run a command like the following:

$ npm install -g [email protected]

To check or confirm what version of SUSHI you have installed, you can run the following command:

$ sushi -v