Skip to content

Releases: FHIR/sushi

SUSHI 2.2.0

12 Nov 20:39
24cb643
Compare
Choose a tag to compare

SUSHI 2.2.0 includes the following enhancements and bug fixes:

  • Allow authors to control if instances should serialize the meta.profile and/or id (#844) (details below)
  • Allow authors to provide instances of logical models (#941) (details below)
  • Allow authors to insert RuleSets at concept paths in CodeSystem definitions (#942)
  • Allow authors to specify mappings for logical models and custom resources (#940)
  • Allow authors to use string values for all ValueSet filter operators (#936)
  • Provide more details and optional configurations in sushi --init config file (#944)
  • Limited support for validating codes defined in local code systems (#595)
  • Limited support for validating slicing logic in profiles (#885, #952)
  • Clarify error message regarding attempts to "widen" cardinality (#943)
  • Fix id generation bug on manually sliced choice elements (#927)
  • Fix dependency loading bug for dependence with version "current" (#951)

Allow Authors to Control if Instances Should Serialize the meta.profile and/or id

By default, SUSHI always generates an instance id and the meta.profile property (for instances of profiles). Now authors can control this by specifying an instanceOptions configuration property in sushi-config.yaml. This configuration allows setMetaProfile and setId sub-properties.

The setMetaProfile value controls whether or not meta.profile is set on generated instances. It can have the following values:

  • always: Set meta.profile for all Instances of profiles (default)
  • never: Do not set meta.profile on any Instances
  • inline-only: Set meta.profile for only Instances of profiles with Usage set to #inline
  • standalone-only: Set meta.profile for only Instances of profiles where Usage is any value other than #inline

The setId value controls whether or not id is set on generated instances. It can have the following values:

  • always: Set id for all Instances (default)
  • standalone-only: Set id for only Instances where Usage is any value other than #inline

The setId flag can't have an inline-only or never option, because the IG Publisher requires ids for non-inline instances.

Allow Authors to Provide Instances of Logical Models

A recent version of the IG Publisher added support for including instances of logical models as binary resources. This feature was announced and discussed in a Logical Model Examples thread on chat.fhir.org. The basic steps an author needs to take in order to include logical model examples in a SUSHI project are:

  1. Add the example to the input/resources or input/examples folder
    a. The file name of the example should be Binary-{id}.json or Binary-{id}.xml (substituting {id} for the real id)
  2. Add an entry for the example in the sushi-config.yaml resources property
    a. Specify a name
    b. Specify exampleCanonical pointing to the canonical of your logical model
    c. Add an extension w/ the proper resource format (application/fhir+json or application/xml)

For example, given the following simple logical model definition in an IG w/ IG canonical root http://example.org:

Logical: MyLM
Id: MyLM
Title: "My LM"
Description: "This is mine"
* important 1..1 SU boolean "Is this resource important"

Create the file input/examples/Binary-my-logical-example.json:

{
  "resourceType": "MyLM",
  "id": "my-logical-example",
  "important": true
}

And add the following in your sushi-config.yaml:

resources:
  Binary/my-logical-example:
    extension:
      - url: http://hl7.org/fhir/StructureDefinition/implementationguide-resource-format
        valueCode: application/fhir+json
    name: Example of LM
    exampleCanonical: http://example.org/StructureDefinition/MyLM

This will result in your logical model example being listed and displayed as a proper example of the logical model.

NOTE: This does not allow/support using the Instance keyword for creating examples of logical models. Authors must created the example as raw JSON or XML. Support for the Instance keyword may come in future versions of SUSHI.

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation, the FSH STU1 specification, and/or the FSH current build 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 stable 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.1.1

08 Oct 19:12
627b66f
Compare
Choose a tag to compare

SUSHI 2.1.1 includes the following bug fix:

  • Remove support for case-insensitive package names. This support was causing failures in the IG auto-build process. This will be added back in a later release. (#912, #800)

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation, the FSH STU1 specification, and/or the FSH current build 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 stable 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.1.0

08 Oct 16:48
fae385f
Compare
Choose a tag to compare

SUSHI 2.1.0 includes the following enhancements and bug fixes:

  • Automatically populate url element on Usage: #definition Instances (#908, #791)
  • Warn when a concept is included in a ValueSet more than once (#913, #832)
  • Support case-insensitive package names (#912, #800) Reverted in 2.1.1 as this causes failures in the IG Publisher auto-build process
  • Display source information when warning about ValueSet filter operand types (#922, #910)
  • Support finding Usage: #definition Instances with InstanceOf: CodeSystem when resolving codes in FSH (#920, #801)
  • Replace errors related to slice cardinality being greater than cardinality of the sliced element with a warning (#926, #918)
  • Fix bug with validation of choice slices when validating cardinality of Instance elements (#916, #911)
  • Update vulnerable dependencies (#917)

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation, the FSH STU1 specification, and/or the FSH current build 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 stable 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.0.1

25 Aug 18:00
cd0549e
Compare
Choose a tag to compare

SUSHI 2.0.1 includes the following enhancements and bug fixes:

  • Support downloading packages via https rather than http (#904)
  • Support including version information in only rules on Canonical types (#898)
  • Fix bug causing soft indexing to fail on indented rules which are not path rules (#907)
  • Fix bugs in sushi --init causing IG Publisher to build with errors (#899)
  • Fix bug causing duplicate detection to only work within a file (#900)
  • Fix bug allowing duplicate concepts to be added to CodeSystem definitions via insert rules (#903)

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation, the FSH STU1 specification, and/or the FSH current build 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 stable 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.0.0

10 Aug 18:30
996509c
Compare
Choose a tag to compare

This is the official, stable SUSHI 2.0.0 release, marking the end of the beta phase for SUSHI 2.0.0. This release fully implements FHIR Shorthand v1.2.0; introducing significant new features, bug fixes, and several breaking changes.

Rule Indentation for Succinct Specification of Subpaths

Indentation can now be used to provide a more succinct visual representation of rules with nested paths. When one rule is indented below another, the full path of the indented rule or rules is obtained by prepending the path from the previous less-indented rule. For example:

* item[0]
  * linkId = "title"
  * type = #display
  * item[0]
    * linkId = "uniquearv_number"
    * type = #string
  * item[1]
    * linkId = "personal_info"
    * type = #group
* status = #active

is equivalent to the more repetitive FSH STU1 approach:

* item[0].linkId = "title"
* item[0].type = #display
* item[0].item[0].linkId = "uniquearv_number"
* item[0].item[0].type = #string
* item[0].item[1].linkId = "personal_info"
* item[0].item[1].type = #group
* status = #active

Using rule indentation is optional. Authors can continue using the longer path form if desired. Existing users should note, however, that this feature assigns meaning to whitespace before the * in rules. Prior to SUSHI 2.0.0, whitespace before the * was insignificant. Existing projects that have arbitrary whitespace before * or put multiple rules on the same line will likely experience errors when running SUSHI 2.0.0. These errors can be fixed by removing unnecessary whitespace before * where needed.

See the following section from the current build FSH specification for additional details:

Logical Models and Custom Resources

Logical models can be defined with the Logical keyword and the optional Parent, Id, Title, and Description keywords. The default parent for logical models is Base. Logical models are useful for representing arbitrary content, since a logical model supports adding elements, unlike profiles and extensions. Elements are added via AddElement rules. These rules specify a path, cardinality, optional flags, type(s), short definition, and optional long definition. For example:

* email 0..* SU string "The person's email addresses" "Email addresses by which the person may be contacted." 

The following demonstrates how logical models could be used to represent a human and their family (also using the optional rule indentation described above):

Logical:        Human
Title:          "Human Being"
Description:    "A member of the Homo sapien species."
* name 0..* SU HumanName "Name(s) of the human" "The names by which the human is or has been known"
* birthDate 0..1 SU dateTime "The date of birth, if known"
    "The date on which the person was born. Approximations may be used if exact date is unknown."
* deceased[x] 0..1 SU boolean or dateTime or Age "Indication if the human is deceased"
    "An indication if the human has died. Boolean should not be used if date or age at death are known."
* family 0..1 BackboneElement "Family" "Members of the human's immediate family."
  * mother 0..2 FamilyMember "Mother" "Biological mother, current adoptive mother, or both."
  * father 0..2 FamilyMember "Father" "Biological father, current adoptive father, or both."
  * sibling 0..* FamilyMember "Sibling" "Other children of the human's mother and/or father."

Logical:        FamilyMember
Title:          "Family Member"
Description:    "A reference to a human's family member."
* human 1..1 SU Reference(Human) "Family member" "A reference to the human family member"
* biological 0..1 boolean "Biologically related?"
      "A family member may not be biologically related due to adoption, blended families, etc."

Custom resources are defined much like logical models, but use the Resource keyword rather than Logical. The default parent for resources is DomainResource.

See the following sections from the current build FSH specification for additional details:

NOTE: The SUSHI team would like to thank Joe Paquette and athenahealth for implementing this feature in SUSHI. Their quality contribution and teamwork has greatly improved SUSHI and allowed the SUSHI team to focus on many of the other proposed FSH STU2 features found in this release. Thank you, Joe and athenahealth!

Hierarchical CodeSystems and Concept-Specific Caret Rules

Concepts in a CodeSystem can now be defined in a hierarchical structure. To define such concepts, list all of the preceding codes in the hierarchy before the new code:

* #{parent code} "{display string}" "{definition string}"
* #{parent code} #{child code} "{display string}" "{definition string}"

This can also be accomplished with indentation:

* #{parent code} "{display string}" "{definition string}"
  * #{child code} "{display string}" "{definition string}"

In addition, authors can now use caret (^) rules on specific concepts to set metadata elements, such as designation and property. For example:

#rash ^designation.use = SCT#900000000000013009 "Synonym"

See the following sections from the current build FSH specification for additional details:

Option to Output Preprocessed FSH

The -p or --preprocessed flag can be used to to create a _preprocessed folder in a SUSHI project. This folder contains representations of the input FSH after several preprocessing steps have taken place. These steps include resolution of Alias values, insertion of RuleSet rules, and resolution of soft indexing. This representation can be useful for investigating errors from SUSHI or other tools. For example, the following FSH:

Alias: CAT = http://hl7.org/fhir/ValueSet/observation-category

Profile: ObservationProfile
Parent: Observation
* insert Metadata
* category from CAT (required)

RuleSet: Metadata
* ^version = "1.2.3"
* ^publisher = "Example publisher"

Instance: PatientInstance
InstanceOf: Patient
* name.given[+] = "John"
* name.given[+] = "Q"

results in the following preprocessed output:

Alias: CAT = http://hl7.org/fhir/ValueSet/observation-category

// Originally defined on lines 3 - 6
Profile: ObservationProfile
Parent: Observation
Id: ObservationProfile
* ^version = "1.2.3"
* ^publisher = "Example publisher"
* category from http://hl7.org/fhir/ValueSet/observation-category (required)

// Originally defined on lines 12 - 15
Instance: PatientInstance
InstanceOf: Patient
Usage: #example
* name.given[0] = "John"
* name.given[1] = "Q"

See the following section from the FSH School SUSHI documentation for additional details:

Extensions for Representing Elements From Other Versions of FHIR

The FHIR specification defines behavior for a feature they refer to as extensions for converting between versions (also known as "implied extensions"). This feature allows authors to represent specific elements from past and future versions of FHIR using a specific extension URL format (as described in the spec linked above). These extensions are not available in any physical package, but rather, are understood and processed conceptually.

To use this feature in SUSHI, authors must specify a dependency on a package using an id and version of the form hl7.fhir.extensions.<extension-version>: <package-version>, where valid extension-versions are r2, r3, r4, and r5. As an example, if an author wanted to represent the Patient.animal.species element as defined in STU3, the dependencies should be specified as:

  dependencies:
    hl7.fhir.extensions.r3: 4.0.1

An author can then reference the extension using a URL following the format defined in the FHIR specification linked above. For example, the extension referring to the R3 Patient.animal.species element would be: http://hl7.org/fhir/3.0/StructureDefinition/extension-Patient.animal.species.

See the following documentation for additional details:

Extension for Profiling BackboneElements

The profile-element extension can be used to profile a BackboneElement by pointing at another BackboneElement defined elsewhere. This is typically used to indicate that constraints on the target of a contentReference should be applied to all the references as well. For example, t...

Read more

SUSHI 2.0.0 Beta 3

28 Jul 20:06
18ef8b0
Compare
Choose a tag to compare
SUSHI 2.0.0 Beta 3 Pre-release
Pre-release

SUSHI 2.0.0-beta.3 is the third beta release for SUSHI 2.0.0. It contains the following enhancements and bug fixes:

  • Updates rule indentation to require that the first rule that sets context be aligned to the left of the document, with no preceding whitespace. Therefore, the first rule in a FSH entity must have no whitespace preceding it and only rules that are indented to use a previous rule's context can have leading whitespace. (#874)
  • Supports creating Profiles of LogicalModels (#857)
  • Supports loading predefined resources from nested folders within the IG template supported input folders (#786)
  • Adds support for checking the type of a StructureDefinition when assigning a value using the Canonical keyword (#870)
  • Properly sets context on rules with no path (such as a caret (^) paths) and on rules that use the . path (#866, #887)
    • Note: The . path is only allowed on top-level rules and cannot be indented
  • Fixes a bug to avoid changing the cardinality of optional slices when a value is assigned (#878)
  • Fixes a bug to allow aliases to be assigned to URLs with fragments (#872)

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation, the FSH STU1 specification, and/or the FSH current build specification.

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 2.0.0 Beta Releases in the Auto Build

The autobuild environment uses the latest stable version of SUSHI. To force the IG Publisher to use SUSHI 2.0.0-beta.3 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=2.0.0-beta.3

SUSHI 2.0.0 Beta 2

01 Jul 20:34
712fa25
Compare
Choose a tag to compare
SUSHI 2.0.0 Beta 2 Pre-release
Pre-release

SUSHI 2.0.0-beta.2 is the second beta release for SUSHI 2.0.0. It contains the following enhancements and bug fixes:

  • Adds support for paths preceding insert rules (#853) (details below)
  • Adds support for Binary Adjunct Files (#819)
  • Supports a code value in the Value Set Filter operators =, in, and not-in (#812)
    • NOTE: The use of a string values in the operators above is now deprecated
  • Adds support for Logical Models and Resources to constrain nested paths of elements they defined (#849)
  • Adds support for using FHIR R4B (4.1.0) as the FHIR version (#855)
  • Adds support for constraining a canonical type to a specific canonical using the Canonical keyword (#846)
    • NOTE: Support for constraining to a canonical w/ a specific version is not yet supported (see #863)
  • Adds a warning when a custom resource is defined using the Resource keyword which is not in the http://hl7.org/fhir/StructureDefinition domain (#842)
  • Fixes a bug so authors can specify a version when referencing a code from a FSH-defined CodeSystem (#816)
  • Fixes a bug related to setting caret paths on code systems codes in a RuleSet (#833)
  • Fixes a bug so that authors can set values on elements that are constrained to a choice of profiles (#794)
    • NOTE: In this case, it will be assigned using the base resource type and a warning will be logged

Insert Rules with Paths

SUSHI now supports specifying a path before using an insert rule. The path that is specified is used throughout all rules in the RuleSet being applied. In the following example, we apply the NameRules RuleSet on the PatientProfile1 profile:

RuleSet: NameRules
* family MS
* given MS

Profile: PatientProfile1
Parent: Patient
* name insert NameRules

which is equivalent to the following profile definition:

Profile: EquivalentProfile
Parent: Patient
* name.family MS
* name.given MS

This also allows insert rules to be used on indented rules. The following profile PatientProfile2 is equivalent to the two profiles above:

Profile: Profile2
Parent: Patient
* name
  * insert NameRules

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation, the FSH STU1 specification, and/or the FSH current build specification.

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 2.0.0 Beta Releases in the Auto Build

The autobuild environment uses the latest stable version of SUSHI. To force the IG Publisher to use SUSHI 2.0.0-beta.2 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=2.0.0-beta.2

SUSHI 2.0.0 Beta 1

04 Jun 19:14
871ef30
Compare
Choose a tag to compare
SUSHI 2.0.0 Beta 1 Pre-release
Pre-release

SUSHI 2.0.0-beta.1 is the first beta release for SUSHI 2.0.0. This release introduces significant new features, bug fixes, and several breaking changes.

New Features

  • Rule indentation for succinct specification of subpaths (#797)
  • Logical models and custom resources (#822)
  • Hierarchical CodeSystems and concept-specific caret rules (#814)
  • Option to output preprocessed FSH (#756)
  • Extensions for representing elements from other versions of FHIR (#805)
  • Extension for profiling BackboneElements (#767)

The above features are detailed further below in the release notes.

Bug Fixes

  • Fixes overly strict checks on assignments to items in an array (#821)
  • Fixes parser to allow more than two value set filters to be chained (#823)

Breaking Changes

  • Indent rules make whitespace before * significant. This may affect a small number of existing IGs.
  • Support for deprecated syntax has been removed (#817), including:
    • Mixins: keyword
    • units keyword
    • , path separator (replaced by and)
    • | type separator (replaced by or)
  • Support for limited ValueSet expansion (added in SUSHI 1.3.0) has been removed (#807)
  • Support for deprecated pre-SUSHI 1.0 project structures has been removed (#820)

All projects using SUSHI 2.0.0-beta.1 must use the project structure described on the Project Structure section of FSH School. Old project structures will now fail with an error. For instructions on migrating from an old project structure, see FSH School's Migration documentation.

Rule Indentation for Succinct Specification of Subpaths

Indentation can now be used to provide a more succinct visual representation of rules with nested paths. When one rule is indented below another, the full path of the indented rule or rules is obtained by prepending the path from the previous less-indented rule. For example:

* item[0]
  * linkId = "title"
  * type = #display
  * item[0]
    * linkId = "uniquearv_number"
    * type = #string
  * item[1]
    * linkId = "personal_info"
    * type = #group
* status = #active

is equivalent to the more repetitive FSH STU1 approach:

* item[0].linkId = "title"
* item[0].type = #display
* item[0].item[0].linkId = "uniquearv_number"
* item[0].item[0].type = #string
* item[0].item[1].linkId = "personal_info"
* item[0].item[1].type = #group
* status = #active

Using rule indentation is optional. Authors can continue using the longer path form if desired. Existing users should note, however, that this feature assigns meaning to whitespace before the * in rules. Prior to SUSHI 2.0.0, whitespace before the * was insignficant. Existing projects that have arbitrary whitespace before * or put multiple rules on the same line will likely experience errors when running SUSHI 2.0.0-beta.1. These errors can be fixed by removing unnecessary whitespace before * where needed.

See the following section from the current build FSH specification for additional details:

Logical Models and Custom Resources

Logical models can be defined with the Logical keyword, and the optional Parent, Id, Title, and Description keywords. The default parent for logical models is Base. Logical models are useful for representing arbitrary content since a logical model supports adding elements, unlike profiles and extensions. Elements are added via an AddElement rule. These rules specify a path, cardinality, optional flags, type(s), short definition, and optional long definition. For example:

* email 0..* SU string "The person's email addresses" "Email addresses by which the person may be contacted." 

The following demonstrates how logical models could be used to represent a human and their family (also using the optional rule indentation described above):

Logical:        Human
Title:          "Human Being"
Description:    "A member of the Homo sapien species."
* name 0..* SU HumanName "Name(s) of the human" "The names by which the human is or has been known"
* birthDate 0..1 SU dateTime "The date of birth, if known"
    "The date on which the person was born. Approximations may be used if exact date is unknown."
* deceased[x] 0..1 SU boolean or dateTime or Age "Indication if the human is deceased"
    "An indication if the human has died. Boolean should not be used if date or age at death are known."
* family 0..1 BackboneElement "Family" "Members of the human's immediate family."
  * mother 0..2 FamilyMember "Mother" "Biological mother, current adoptive mother, or both."
  * father 0..2 FamilyMember "Father" "Biological father, current adoptive father, or both."
  * sibling 0..* FamilyMember "Sibling" "Other children of the human's mother and/or father."

Logical:        FamilyMember
Title:          "Family Member"
Description:    "A reference to a human's family member."
* human 1..1 SU Reference(Human) "Family member" "A reference to the human family member"
* biological 0..1 boolean "Biologically related?"
      "A family member may not be biologically related due to adoption, blended families, etc."

Custom resources are defined much like logical models, but use the Resource keyword rather than Logical. The default parent for resources is DomainResource.

See the following sections from the current build FSH specification for additional details:

NOTE: The SUSHI team would like to thank Joe Paquette and athenahealth for implementing this feature in SUSHI. Their quality contribution and teamwork has greatly improved SUSHI and allowed the SUSHI team to focus on many of the other proposed FSH STU2 features found in this release. Thank you, Joe and athenahealth!

Hierarchical CodeSystems and Concept-Specific Caret Rules

Concepts in a CodeSystem can now be defined in a hierarchical structure. To define such concepts, list all of the preceding codes in the hierarchy before the new code:

* #{parent code} "{display string}" "{definition string}"
* #{parent code} #{child code} "{display string}" "{definition string}"

This can also be accomplished with indentation:

* #{parent code} "{display string}" "{definition string}"
  * #{child code} "{display string}" "{definition string}"

In addition, authors can now use caret (^) rules on specific concepts to set metadata elements such as designation and property. For example:

#rash ^designation.use = SCT#900000000000013009 "Synonym"

See the following sections from the current build FSH specification for additional details:

Option to Output Preprocessed FSH

The -p or --preprocessed flag can be used to to create a _preprocessed folder in a SUSHI project. This folder contains representations of the input FSH after several preprocessing steps have taken place. These steps include resolution of Alias values, insertion of RuleSet rules, and resolution of soft indexing. For example, the following FSH:

Alias: CAT = http://hl7.org/fhir/ValueSet/observation-category

Profile: ObservationProfile
Parent: Observation
* insert Metadata
* category from CAT (required)

RuleSet: Metadata
* ^version = "1.2.3"
* ^publisher = "Example publisher"

Instance: PatientInstance
InstanceOf: Patient
* name.given[+] = "John"
* name.given[+] = "Q"

results in the following preprocessed output:

Alias: CAT = http://hl7.org/fhir/ValueSet/observation-category

// Originally defined on lines 3 - 6
Profile: ObservationProfile
Parent: Observation
Id: ObservationProfile
* ^version = "1.2.3"
* ^publisher = "Example publisher"
* category from http://hl7.org/fhir/ValueSet/observation-category (required)

// Originally defined on lines 12 - 15
Instance: PatientInstance
InstanceOf: Patient
Usage: #example
* name.given[0] = "John"
* name.given[1] = "Q"

See the following section from the FSH School SUSHI documentation for additional details:

Extensions for Representing Elements From Other Versions of FHIR

The FHIR specification defines behavior for a feature they refer to as extensions for converting between versions (also known as "implied extensions"). This feature allows authors to represent specific elements from past and future versions of FHIR using a specific extension URL format (as described in the spec linked above). These extensions are not available in any physical package, but rather, are understood and processed conceptually.

To use this feature in SUSHI, authors must specify a dependency on a package using an id and version of the form hl7.fhir.extensions.<extension-version>: <package-version>, whe...

Read more

SUSHI 1.3.2

23 Apr 17:52
4257889
Compare
Choose a tag to compare

SUSHI 1.3.2 includes the following bug fixes:

  • Skip nonexistent files when traversing directories (#780)
  • Fix bug which causes soft indexing sequences to always start at index 0 (#792)
  • Fix bug with adding extensions to ElementDefinitions (#759)
  • Loosen restrictions on constraining profiled types (#789)
  • Provide more helpful error messages when authors try to bind a CodeSystem where a ValueSet should be used, or try to assign a ValueSet where a CodeSystem should be used (#538)

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation, the FSH STU1 specification, and/or the FSH current build 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 stable 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 1.3.1

24 Mar 15:32
9dc8af0
Compare
Choose a tag to compare

SUSHI 1.3.1 includes the following enhancements and bug fixes:

  • Improved support for R5 CodeableReference type (details below)
  • Don't export untyped value[x] properties in instances (#760)
  • Fix bug that caused arrays to sometimes be exported as single items (#776)
  • Fix handling of only rules when profiles are applied to elements with existing slices (#769)
  • Fix typos in logging statements (#779)

Improved Support for R5 CodeableReference Type

SUSHI now provides improved support for the FHIR R5 CodeableReference type. Authors can now apply bindings directly to CodeableReferences and directly constrain types on CodeableReferences. In the following example, we constrain Substance.code, which is a CodeableReference(SubstanceDefinition):

Profile: LatexSubstance
Parent: Substance
// restrict code concept to LatexCodes value set
* code from LatexCodes
// restrict code reference from SubstanceDefinition to LatexSubstanceDefinition profile
* code only Reference(LatexSubstanceDefinition)

Note that in an Instance, authors cannot assign a CodeableReference directly, but rather, should assign one (or both) of its parts. For example:

Instance: MyLatexSubstanceExample
InstanceOf: LatexSubstance
* code.concept = SCT#1003754000 "Natural rubber latex (substance)"
* code.reference = Reference(MyNaturalLatexDefinitionExample)

Full Documentation

For additional documentation, refer to FSH School's SUSHI documentation, the FSH STU1 specification, and/or the FSH current build 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 stable 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