Skip to content
This repository has been archived by the owner on Oct 17, 2019. It is now read-only.

Releases: standardhealth/shr-cli

5.13.0

08 Jan 18:49
50b8a88
Compare
Choose a tag to compare

Version 5.13.0 introduces several enhancements and bug fixes to FHIR export:

  • New mapping feature to indicate that certain elements should not produce profiles (e.g., Patient or Encounter)
  • Simplified names and titles of profiles, extensions, logical models, value sets, and code systems
  • Allow mappings of Coding to code or CodeableConcept (standardhealth/shr-cli#131)
  • Properly handle cardinality when mapping to extensions (standardhealth/shr-cli#136)
  • Remove redundant/invalid targetProfile property from DSTU2 type elements

To use the new feature to indicate that a certain element shouldn't produce a profile, even if there are meaningful differences, add (no profile) after the top-level element mapping but before the colon. For example:

Patient maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-patient (no profile):
	Person.ActiveFlag maps to active
	Person.HumanName maps to name
	Person.AdministrativeGender maps to gender
	Person.PhotographicImage maps to photo
	Person.Address maps to address
	Person.ContactPoint maps to telecom
	Person.LanguageUsed.Language maps to communication
	Person.DateOfBirth maps to birthDate
	Person.MaritalStatus maps to maritalStatus
	Person.BirthSex maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-birthsex
	Person.Race maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-race
	Person.Ethnicity maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-ethnicity

The above mapping would prevent a profile for shr-entity-Patient from being built. This means that any other profiles that would reference an shr-entity-Patient will reference the argo-patient instead.

Note that this may have implications for code generation and toFHIR (TBD) / fromFHIR (to be released today) capability. By keeping the individual mapping statements in the mapping, some mapping data will be logged for toFHIR/fromFHIR to use, but if there are items not in argo-profile at all, then not much can be done.

5.13.0 Beta 1

20 Dec 06:33
Compare
Choose a tag to compare
5.13.0 Beta 1 Pre-release
Pre-release

Version 5.13.0 introduces several enhancements and bug fixes to FHIR export:

  • New mapping feature to indicate that certain elements should not produce profiles (e.g., Patient or Encounter)
  • Simplified names and titles of profiles, extensions, logical models, value sets, and code systems
  • Allow mappings of Coding to code or CodeableConcept (standardhealth/shr-cli#131)
  • Properly handle cardinality when mapping to extensions (standardhealth/shr-cli#136)
  • Remove redundant/invalid targetProfile property from DSTU2 type elements

To use the new feature to indicate that a certain element shouldn't produce a profile, even if there are meaningful differences, add (no profile) after the top-level element mapping but before the colon. For example:

Patient maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-patient (no profile):
	Person.ActiveFlag maps to active
	Person.HumanName maps to name
	Person.AdministrativeGender maps to gender
	Person.PhotographicImage maps to photo
	Person.Address maps to address
	Person.ContactPoint maps to telecom
	Person.LanguageUsed.Language maps to communication
	Person.DateOfBirth maps to birthDate
	Person.MaritalStatus maps to maritalStatus
	Person.BirthSex maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-birthsex
	Person.Race maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-race
	Person.Ethnicity maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-ethnicity

The above mapping would prevent a profile for shr-entity-Patient from being built. This means that any other profiles that would reference an shr-entity-Patient will reference the argo-patient instead.

Note that this may have implications for code generation and the currently in-progress toFHIR and fromFHIR capability. By keeping the individual mapping statements in the mapping, some mapping data will be logged for toFHIR/fromFHIR to use, but if there are items not in argo-profile at all, then not much can be done.

5.12.1

03 Dec 13:39
02b6c57
Compare
Choose a tag to compare

Versions 5.12.x introduce support for creating FHIR DSTU2 implementation guides. In addition, they allow authors to map data elements to Argonaut profiles. Currently DSTU2 logical models are not supported, but they will be added in a follow-on release.

The version 5.12.1 patch release addresses a bug in FHIR export related to resolving paths in target profiles.

To map to DSTU2 and/or Argonaut, declare the FHIR_DSTU_2 target in your mapping file. For example:

Grammar:   Map 5.0
Namespace: shr.simple
Target:    FHIR_DSTU_2

You must ensure that your mapping statements refer to valid DSTU2 resources and attributes (for example, MedicationOrder rather than MedicationRequest). To map to an Argonaut profile, use the Argonaut defining URL. For example:

MyCondition maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-condition:
Value maps to code

If your project only contains mappings to a single FHIR version, the SHR CLI will automatically detect the correct version to export. If your project contains mappings for both FHIR_DSTU_2 and FHIR_STU_3, then you must declare what version to export via the fhirTarget property in your config file. For example:

"fhirTarget": "FHIR_DSTU_2",

Known limitations that will be addressed in a future release:

  • FHIR DSTU2 logical models are not yet supported

Known limitations in the FHIR IG Publishing Tools and/or spec:

  • DSTU2 ids do not allow the characters :, [, or ], making it unclear how slices and choices should be indicated in the id. As a result, ids have been removed from the profile elements (which is valid in DSTU2). (Zulip)
  • The IG publisher cannot process formal dependency on the Argonaut IG, affecting its ability to expand Argonaut value sets. (Zulip)
  • The IG publisher fails to expand inline code systems. (Zulip)
  • The extension modifier icon is missing from the publisher, causing broken images in the snapshot/differential tables. (Zulip)
  • The IG publisher reports a QA error about missing resources in the ig.xml file, even though they are actually there. This does not appear to affect the output of the IG. (Zulip)
  • Recent builds of the IG Publisher have broken compatibility with network proxies. As a result, the CLI tool uses the October 1 build of the IG publisher. (Zulip)

5.12.0

28 Nov 18:16
8158eaa
Compare
Choose a tag to compare

Version 5.12.0 introduces support for creating FHIR DSTU2 implementation guides. In addition, it allows authors to map data elements to Argonaut profiles. Currently DSTU2 logical models are not supported, but they will be added in a follow-on release.

To map to DSTU2 and/or Argonaut, declare the FHIR_DSTU_2 target in your mapping file. For example:

Grammar:   Map 5.0
Namespace: shr.simple
Target:    FHIR_DSTU_2

You must ensure that your mapping statements refer to valid DSTU2 resources and attributes (for example, MedicationOrder rather than MedicationRequest). To map to an Argonaut profile, use the Argonaut defining URL. For example:

MyCondition maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-condition:
Value maps to code

If your project only contains mappings to a single FHIR version, the SHR CLI will automatically detect the correct version to export. If your project contains mappings for both FHIR_DSTU_2 and FHIR_STU_3, then you must declare what version to export via the fhirTarget property in your config file. For example:

"fhirTarget": "FHIR_DSTU_2",

Known limitations that will be addressed in a future release:

  • FHIR DSTU2 logical models are not yet supported

Known limitations in the FHIR IG Publishing Tools and/or spec:

  • DSTU2 ids do not allow the characters :, [, or ], making it unclear how slices and choices should be indicated in the id. As a result, ids have been removed from the profile elements (which is valid in DSTU2). (Zulip)
  • The IG publisher cannot process formal dependency on the Argonaut IG, affecting its ability to expand Argonaut value sets. (Zulip)
  • The IG publisher fails to expand inline code systems. (Zulip)
  • The extension modifier icon is missing from the publisher, causing broken images in the snapshot/differential tables. (Zulip)
  • The IG publisher reports a QA error about missing resources in the ig.xml file, even though they are actually there. This does not appear to affect the output of the IG. (Zulip)
  • Recent builds of the IG Publisher have broken compatibility with network proxies. As a result, the CLI tool uses the October 1 build of the IG publisher. (Zulip)

5.12.0 Beta 4

20 Nov 20:28
Compare
Choose a tag to compare
5.12.0 Beta 4 Pre-release
Pre-release

Version 5.12.0 beta versions introduce support for creating FHIR DSTU2 implementation guides. In addition, they allow authors to map data elements to Argonaut profiles.

Beta 4 includes the following changes from Beta 3:

  • Sets constrainedType on DSTU2 profiles
  • Fixes incorrect path to discriminator (eliminating incorrectly reported errors in the CLI)
  • Fixes support for Basic Type codes in DSTU2 to use a value set instead of code system
  • Fixes crashes when determining primary value sets in DSTU2 IGs

To map to DSTU2 and/or Argonaut, declare the FHIR_DSTU_2 target in your mapping file. For example:

Grammar:   Map 5.0
Namespace: shr.simple
Target:    FHIR_DSTU_2

You must ensure that your mapping statements refer to valid DSTU2 resources and attributes (for example, MedicationOrder rather than MedicationRequest). To map to an Argonaut profile, use the Argonaut defining URL. For example:

MyCondition maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-condition:
Value maps to code

If your project only contains mappings to a single FHIR version, the SHR CLI will automatically detect the correct version to export. If your project contains mappings for both FHIR_DSTU_2 and FHIR_STU_3, then you must declare what version to export via the fhirTarget property in your config file. For example:

"fhirTarget": "FHIR_DSTU_2",

Known limitations that will be addressed in a future release:

  • FHIR DSTU2 logical models are not yet supported

Known limitations in the FHIR IG Publishing Tools and/or spec:

  • DSTU2 ids do not allow the characters :, [, or ], making it unclear how slices and choices should be indicated in the id. As a result, ids have been removed from the profile elements (which is valid in DSTU2). (Zulip)
  • The IG publisher cannot process formal dependency on the Argonaut IG, affecting its ability to expand Argonaut value sets. (Zulip)
  • The IG publisher fails to expand inline code systems. (Zulip)
  • The IG publisher fails to create schematrons for DSTU2 profiles. (Zulip)
  • The extension modifier icon is missing from the publisher, causing broken images in the snapshot/differential tables. (Zulip)
  • The IG publisher reports a QA error about missing resources in the ig.xml file, even though they are actually there. This does not appear to affect the output of the IG. (Zulip)
  • Recent builds of the IG Publisher have broken compatibility with network proxies. As a result, the CLI tool uses the October 1 build of the IG publisher. (Zulip)

5.12.0 Beta 3

05 Nov 19:04
Compare
Choose a tag to compare
5.12.0 Beta 3 Pre-release
Pre-release

Version 5.12.0 beta versions introduce support for creating FHIR DSTU2 implementation guides. In addition, they allow authors to map data elements to Argonaut profiles.

Beta 3 includes the following changes from Beta 2:

  • Adds "hybrid" strategy to primarySelectionStrategy

To map to DSTU2 and/or Argonaut, declare the FHIR_DSTU_2 target in your mapping file. For example:

Grammar:   Map 5.0
Namespace: shr.simple
Target:    FHIR_DSTU_2

You must ensure that your mapping statements refer to valid DSTU2 resources and attributes (for example, MedicationOrder rather than MedicationRequest). To map to an Argonaut profile, use the Argonaut defining URL. For example:

MyCondition maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-condition:
Value maps to code

If your project only contains mappings to a single FHIR version, the SHR CLI will automatically detect the correct version to export. If your project contains mappings for both FHIR_DSTU_2 and FHIR_STU_3, then you must declare what version to export via the fhirTarget property in your config file. For example:

"fhirTarget": "FHIR_DSTU_2",

Known limitations that will be addressed in a future release:

  • FHIR DSTU2 logical models are not yet supported

Known limitations in the FHIR IG Publishing Tools and/or spec:

  • DSTU2 ids do not allow the characters :, [, or ], making it unclear how slices and choices should be indicated in the id. As a result, ids have been removed from the profile elements (which is valid in DSTU2). (Zulip)
  • The IG publisher cannot process formal dependency on the Argonaut IG, affecting its ability to expand Argonaut value sets. (Zulip)
  • The IG publisher fails to expand inline code systems. (Zulip)
  • The IG publisher fails to create schematrons for DSTU2 profiles. (Zulip)
  • The extension modifier icon is missing from the publisher, causing broken images in the snapshot/differential tables. (Zulip)
  • The IG publisher reports a QA error about missing resources in the ig.xml file, even though they are actually there. This does not appear to affect the output of the IG. (Zulip)
  • Recent builds of the IG Publisher have broken compatibility with network proxies. As a result, the CLI tool uses the October 1 build of the IG publisher. (Zulip)

5.12.0 Beta 2

05 Nov 18:41
Compare
Choose a tag to compare
5.12.0 Beta 2 Pre-release
Pre-release

NOTE: Updated tag/download: This release was previously referencing the wrong commit. This has been corrected.

Version 5.12.0 beta versions introduce support for creating FHIR DSTU2 implementation guides. In addition, they allow authors to map data elements to Argonaut profiles.

Beta 2 includes the following changes from Beta 1:

  • Fixed contents of Downloads page
  • Removed Code Systems page from the navigation

To map to DSTU2 and/or Argonaut, declare the FHIR_DSTU_2 target in your mapping file. For example:

Grammar:   Map 5.0
Namespace: shr.simple
Target:    FHIR_DSTU_2

You must ensure that your mapping statements refer to valid DSTU2 resources and attributes (for example, MedicationOrder rather than MedicationRequest). To map to an Argonaut profile, use the Argonaut defining URL. For example:

MyCondition maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-condition:
Value maps to code

If your project only contains mappings to a single FHIR version, the SHR CLI will automatically detect the correct version to export. If your project contains mappings for both FHIR_DSTU_2 and FHIR_STU_3, then you must declare what version to export via the fhirTarget property in your config file. For example:

"fhirTarget": "FHIR_DSTU_2",

Known limitations that will be addressed in a future release:

  • FHIR DSTU2 logical models are not yet supported

Known limitations in the FHIR IG Publishing Tools and/or spec:

  • DSTU2 ids do not allow the characters :, [, or ], making it unclear how slices and choices should be indicated in the id. As a result, ids have been removed from the profile elements (which is valid in DSTU2). (Zulip)
  • The IG publisher cannot process formal dependency on the Argonaut IG, affecting its ability to expand Argonaut value sets. (Zulip)
  • The IG publisher fails to expand inline code systems. (Zulip)
  • The IG publisher fails to create schematrons for DSTU2 profiles. (Zulip)
  • The extension modifier icon is missing from the publisher, causing broken images in the snapshot/differential tables. (Zulip)
  • The IG publisher reports a QA error about missing resources in the ig.xml file, even though they are actually there. This does not appear to affect the output of the IG. (Zulip)
  • Recent builds of the IG Publisher have broken compatibility with network proxies. As a result, the CLI tool uses the October 1 build of the IG publisher. (Zulip)

5.12.0 Beta 1

04 Nov 21:19
Compare
Choose a tag to compare
5.12.0 Beta 1 Pre-release
Pre-release

Version 5.12.0 Beta 1 introduces support for creating FHIR DSTU2 implementation guides. In addition, it allows authors to map data elements to Argonaut profiles.

To map to DSTU2 and/or Argonaut, declare the FHIR_DSTU_2 target in your mapping file. For example:

Grammar:   Map 5.0
Namespace: shr.simple
Target:    FHIR_DSTU_2

You must ensure that your mapping statements refer to valid DSTU2 resources and attributes (for example, MedicationOrder rather than MedicationRequest). To map to an Argonaut profile, use the Argonaut defining URL. For example:

MyCondition maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-condition:
Value maps to code

If your project only contains mappings to a single FHIR version, the SHR CLI will automatically detect the correct version to export. If your project contains mappings for both FHIR_DSTU_2 and FHIR_STU_3, then you must declare what version to export via the fhirTarget property in your config file. For example:

"fhirTarget": "FHIR_DSTU_2",

There is also functionality to filter the IG by a hybrid strategy. By changing the filterStrategy.strategy in the config file to "hybrid", you can input both namespaces and elements into the target array.

Known limitations that will be addressed in a future release:

  • FHIR DSTU2 logical models are not yet supported
  • The exported IG contains a "Code Systems" page even though FHIR DSTU2 does not support independently defined code systems

Known limitations in the FHIR IG Publishing Tools and/or spec:

  • DSTU2 ids do not allow the characters :, [, or ], making it unclear how slices and choices should be indicated in the id. As a result, ids have been removed from the profile elements (which is valid in DSTU2). (Zulip)
  • The IG publisher cannot process formal dependency on the Argonaut IG, affecting its ability to expand Argonaut value sets. (Zulip)
  • The IG publisher fails to expand inline code systems. (Zulip)
  • The IG publisher fails to create schematrons for DSTU2 profiles. (Zulip)
  • The extension modifier icon is missing from the publisher, causing broken images in the snapshot/differential tables. (Zulip)
  • The IG publisher reports a QA error about missing resources in the ig.xml file, even though they are actually there. This does not appear to affect the output of the IG. (Zulip)
  • Recent builds of the IG Publisher have broken compatibility with network proxies. As a result, the CLI tool uses the October 1 build of the IG publisher. (Zulip)

5.11.0

13 Sep 13:48
7ad404d
Compare
Choose a tag to compare

Version 5.11.0 includes the following changes:

  • Support for importing CIMCORE JSON instead of CIMPL source
    • Example: node . -i /path/to/folder/containing/cimcore
  • Logical models fixes:
    • Choices should have names ending with [x], but collapsing sometimes caused this not to be the case.
    • Collapsing elements that indicated a specific selection in a choice caused incorrectly formed ids and paths.
    • Models were sometimes generated multiple times, which is inefficient, but in some cases also caused inconsistent results.
    • Card constraints should be applied first in logical models because other constraints may operate on or modify the card.

5.10.0

31 Aug 15:04
2868823
Compare
Choose a tag to compare

Version 5.10.0 is a significant release, reflecting many changes made to support the HL7 FHIR September ballot process:

  • Initial ADL/BMM exporter
    • Disabled by default, use the -a or --adl flags to enable
    • Requires provenanceInfo to be added to config.json file:
    "provenanceInfo": {
        "leadAuthor": {
            "name":"Example Author",
            "organization": "Example Publisher",
            "email": "[email protected]"
        },
        "license": "Creative Commons CC-BY <https://creativecommons.org/licenses/by/3.0/>",
        "copyright": "Copyright (c) The Example Organization <http://example.org>"
    }
    
  • Text Importer:
    • Log an error when duplicate definitions are found (same name in same namespace)
    • Allow sub-elements to refer to referenced fields without the ref(...) when constraining them
  • CIMCORE
    • Fix an issue with creating CIMCORE output directories on Windows machines
    • Fix support for exporting CIMCORE when there are no mapping files
    • Improve support for exporting CIMCORE when there are mappings to multiple targets
  • ModelDoc
    • Do not create links from value set URIs (as they often are not resolvable)
    • Escape < and > in descriptions when generating markdown
  • FHIR IG config:
    • Support for multiple pages of documentation by putting them in a folder and referencing the folder via config.implementationGuide.indexContent
    • Add support for "hiding" supporting profiles/models/extensions/valuesets/codesystems via config.implementationGuide.primarySelectionStrategy.hideSupporting
      • Primary extensions are defined as only those extensions directly used by primary profiles
      • Primary value sets and code systems are those that are directly referenced by primary profiles and extensions or are defined in the primary namespace
    • Allow fixed-business-version to be controlled by config.implementationGuide.version
    • Allow npm-name to be controlled by config.implementationGuide.npmName
    • Allow history link to be controlled by config.implementationGuide.historyLink
    • Fix incorrect casing on license
    • Add version for uscore dependency (1.0.1)
  • FHIR IG rendering:
    • Update to latest IG Publisher jar
    • Improve display of listing pages when there is nothing to list
    • Fix empty descriptions from being rendered as 'undefined'
    • Remove the download link for the full IG
    • Move copyright symbol in footer
    • Remove pub tools version number from footer
  • FHIR Profiles:
    • Improve handling of slices inside of slices
    • Support type constraints on elements inside extensions
    • Support direct IncludesType constraints on extensions
    • Create a code system to define the codes used by profiles on Basic (HL7/us-breastcancer#6)
    • Fix type constraints on choices to properly narrow choices in FHIR profile element
    • Fix specialized types to use base type when constraining choices (HL7/us-breastcancer#11)
    • Fix incorrect constraint merging logic (standardhealth/shr-spec#73)
    • Fix incorrect slicing base on extensions
    • Fix bug which could potentially cause infinite loops
    • Fix to better identify no-diff profiles (and not create unnecessary differentials) (standardhealth/shr-cli#116)
    • Don't inherit examples from FHIR resources when creating profiles (HL7/us-breastcancer#3)
    • Always trim description and short fields to remove trailing spaces
  • FHIR Logical Models:
    • Create "compact" models that eliminate unecessary levels of indirection
    • Fix duplicate Codings (HL7/us-breastcancer#5)