Releases: standardhealth/shr-cli
5.13.0
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
tocode
orCodeableConcept
(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
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
tocode
orCodeableConcept
(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
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
id
s do not allow the characters:
,[
, or]
, making it unclear how slices and choices should be indicated in theid
. As a result,id
s 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
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
id
s do not allow the characters:
,[
, or]
, making it unclear how slices and choices should be indicated in theid
. As a result,id
s 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
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
id
s do not allow the characters:
,[
, or]
, making it unclear how slices and choices should be indicated in theid
. As a result,id
s 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
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
id
s do not allow the characters:
,[
, or]
, making it unclear how slices and choices should be indicated in theid
. As a result,id
s 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
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
id
s do not allow the characters:
,[
, or]
, making it unclear how slices and choices should be indicated in theid
. As a result,id
s 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
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
id
s do not allow the characters:
,[
, or]
, making it unclear how slices and choices should be indicated in theid
. As a result,id
s 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
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
- Example:
- 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
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>" }
- Disabled by default, use the
- 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
- See standardhealth/shr-fhir-export#100 for details
- 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 byconfig.implementationGuide.version
- Allow
npm-name
to be controlled byconfig.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
)
- Support for multiple pages of documentation by putting them in a folder and referencing the folder via
- 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)