Which kinds of log output messages to produce - the value is a code, from this list:

• init: Messages describing the start up process (for debugging)
• progress: Overall progress messages
• tx: Messages describing the use of the terminology server (for debugging)
• generate: Log when producing an individual resource (troubleshooting only - leave off)
• html: Log when validating an html page (troubleshooting only - leave off)

Fine grained control over generation of resources:

• example-narratives: generate narrative in examples if they don't have any (as opposed to conformance resources, which are always generated)
• genExamples: produce extra examples (todo: document this)

Except: you can't turn example-narratives off. Todo: decide why this exists. But you can suppress - see next item

A resource to suppress narrative generation for (and Resource.text will be removed if found). Format is (type)/(id) e.g. Patient/example, or type or id may be * e.g. Task/* - do not generate narrative for any Task resource.

Narrative Generation should never be suppressed for any canonical resource

Note for HL7 users: the FMG will review which resources have narrative suppressed and why when publication approval is sought

A resource not to validate. Format is (type)/(id) e.g. Patient/example, or type or id may be * e.g. Task/* - do not validate any Task resource.

Suppressing validation is generally a bad idea. There's two contexts where it might be useful: validation of really big resources that takes a long time, and examples that are purposefully wrong to demonstrate what not to do. But while it sounds good - don't bother me with problems I mean to introduce, it's too easy for other unintended problems to accumulate. So it's better to keep validation on.

ote for HL7 users: the FMG will review which resources have validation suppressed and why when publication approval is sought. FMG would generally prefer to see explicit errors for resources that are wrong intentionally, and will OK publication in this case. It's going to reviewed either way.

Do not check usage for extensions and data types - for IGs where they are being defined for use elsewhere

Relative path to a location in the IG repository from which to load resources. If the path ends in /*, then that means all sub-folders

Relative path to a location in the IG repository in which to look for binary adjunct files. These files are only used in the context of the CQL loader

If true, scan the locations in which resources might be found (above) looking for resources, and auto-loading them. Else, only load what is in the IG.

A code system property to show when rendering code systems (code system property definitions with a 'rendered-value' extension are always shown, as is any property in the uri space http://hl7.org/fhir/concept-properties

A relative path in which page source material can be found. In spite of the implication of the name, the materials in this directory are not processed, they are passed through to Jekyll untouched

A relative path in which data files can be found (will go in _data for Jekyll).

The relative path to the qa folder (generated fragments to check rendering in browser).

The relative path to the terminology cache.

A relative path that contains liquid templates for generating narrative

The relative path to use for jekyll processing.

The relative path where the output is generated.

The url where the history file is found (usually (canonical)/history.html). Used when checking links

The relative path to a parameters resource that contains expansion parameters used when the IG publisher expands a value set

A file to load suppressed error messages from (one msg per line). Suppressed errors don't chose up in the qa.ini (but will be checked anyway if publishing through HL7 processes)

Indicates a folder that contains useful testing collateral to include a /test folder in the package. If more than one value is provided, the contents are all added to the one folder (in order)

A mask that identifies specific HTML files exempt from having header / footer etc.

Discuss with FHIR Product Manager before using in any HL7 IG

An external domain from which extensions are allowed to come (else they'll be flagged as invalid when validating). http://example.org is always allowed

Whether to generate active tables in the generated fragments (tables that will expand and contract). Note that turning this on requires that this entry be found somewhere in the header of the generated html pages: \<script src='fhir-table-scripts.js'>\</script>

If a canonical resource in the IG should actually have a URL that isn't the one implied by the canonical URL for the IG itself, it must be listed here explicitly (as well as defined in the resource itself). It must be listed here to stop it accidentally being different. Each canonical url must be listed in full as present on the resource; it is not possible to specify a pattern.

A common alternative base URL for multiple canonical resources in the IG

A relative path to the template openapi file to use when generating openapi files (e.g. populate openAPI security details)

A relative path to the template to use when rendering html pages

A relative path to the template to use when rendering markdown pages

if true, overwrite all canonical resource contact details with that found in the IG.

(Note: the ig-template-base template, on which almost all IG templates are based, sets this to parameter to true unless it has been explicitly set.)

if true, populate all canonical resources that don't specify their own contact details with that found in the IG. Ignored if apply-contact is true.

if true, overwrite all canonical resource context details with that found in the IG.

(Note: the ig-template-base template, on which almost all IG templates are based, sets this to parameter to true unless it has been explicitly set.)

if true, populate all canonical resources that don't specify their own context details with that found in the IG. Ignored if apply-context is true.

if true, overwrite all canonical resource copyright details with that found in the IG.

(Note: the ig-template-base template, on which almost all IG templates are based, sets this to parameter to true unless it has been explicitly set.)

if true, populate all canonical resources that don't specify their own copyright details with that found in the IG. Ignored if apply-copyright is true.

if true, overwrite all canonical resource jurisdiction details with that found in the IG.

(Note: the ig-template-base template, on which almost all IG templates are based, sets this to parameter to true unless it has been explicitly set.)

if true, populate all canonical resources that don't specify their own jurisdiction details with that found in the IG. Ignored if apply-jurisdiction is true.

if true, overwrite all canonical resource license details with that found in the IG.

(Note: the ig-template-base template, on which almost all IG templates are based, sets this to parameter to true unless it has been explicitly set.)

if true, populate all canonical resources that don't specify their own license details with that found in the IG. Ignored if apply-license is true.

if true, overwrite all canonical resource publisher details with that found in the IG.

(Note: the ig-template-base template, on which almost all IG templates are based, sets this to parameter to true unless it has been explicitly set.)

if true, populate all canonical resources that don't specify their own publisher details with that found in the IG. Ignored if apply-publisher is true.

if true, overwrite all canonical resource version details with that found in the IG.

(Note: the ig-template-base template, on which almost all IG templates are based, sets this to parameter to true unless it has been explicitly set.)

if true, populate all canonical resources that don't specify their own version details with that found in the IG. Ignored if apply-version is true.

if true, overwrite all canonical resource WG details with that found in the IG.

(Note: the ig-template-base template, on which almost all IG templates are based, sets this to parameter to true unless it has been explicitly set.)

if true, populate all canonical resources that don't specify their own WG details with that found in the IG. Ignored if apply-contact is true.

If true, indicates that the FMM and Standards Status declarations from top-level artifacts should be propagated to any dependencies that don't declare their own values. If different statuses or maturity level would propagate to a dependency from different artifacts, the 'highest' FMM or most mature standards status will apply (Normative or Informative, then STU, then Draft). Information does not propagate to artifacts marked as examples or as experimental. Propagation is based on references. E.g. the IG references everything (so its status will propagate everywhere by default). If there are higher statuses on certain CapabilityStatements, Operations or Profiles, those status will propagate to the artifacts they reference, such as other profiles, ValueSets or CodeSystems. Propagation only happens within the context of an IG. There is no propagation across artifacts present in other IG packages listed as dependencies.

Fine grained control over validation flags when validating resources / IGs:

• check-must-support: Does nothing! (for now?)
• allow-any-extensions: Allow any extensions at all (and therefore miss accidental broken extension references)
• check-aggregation: check that aggregation is correct (in IGs, bundles are often broken up for publishing / documentation purposes)
• no-broken-links: forbid broken links in HTML pages - stop the build if any are found
• show-reference-messages: when validating, instead of showing a summary of issues from validating the target of references, just show all the validation messages in detail
• no-experimental-content: create an error if the IG contains any experimental content

faIf true, render inherited constraints in the full details and invariants viewlse

if true, show the warning when codes are not in extensible bindings

If true, usage stats (information about extensions, value sets, and invariants being used) is not sent to fhir.org (see e.g. http://clinfhir.com/igAnalysis.html).

Request that the IG publisher generate packages for additional versions than the stated version e.g. the IG might be for authored against version 4.0, but also produce an R3 version.

For each occurence of this parameter, the IG publisher will produce an extra package, with the filename id.ver.tgz where id is the main id of the ig, and ver is the parameter value. (note that this is different to the main package which is always called package.tgz).

This parameter can have one one of following values:

• r2
• r2b
• r3
• r4
• r5

This parameter should be used with great care, and only after consulting the FHIR Product director to consider all of it's ramifications. It's generally only appropriate for terminology resources. It's not an error to generate the same version as the IG itself - this is typically done for consistency of use across versions

The release label at the top of the page. This is a text label with no fixed set of values that describes the status of the publication to users. Typical values might be 'STU X' or 'Normative Standard' or '2024 Edition'

Cause the publisher to exclude the generation of the xml format and to exclude the xml tab from the implementation guide pages.

Cause the publisher to exclude the generation of the json format and to exclude the json tab from the implementation guide pages.

Cause the publisher to exclude the generation of the ttl format and to exclude the ttl tab from the implementation guide pages.

If true, causes the mapping tab to be excluded from all StructureDefinition artifact pages

If true, causes the xml, json and ttl tabs to be excluded for Binary resources when they're examples of logical models

Determines whether the next/previous navigation tabs are shown in the header and footer

The copyright year text to include in the implementation guide footer

Indicates the URL that provides a definition for the maturity levels declared in the current IG.

Control how the IG publisher does a comparison with a previously published version (see qa.html). Possible values:

• {last} - compare with the last published version (whatever it's status) - this is the default if the parameter doesn't appear
• {current} - compare with the last full published version
• n/a - don't do any comparison
• [v] - a previous version where [v] is the version

Provide this parameter to instruct the IG publisher to mark up the generated pages with the differences found for the version specified. This version can be listed in version-comparison too but it doesn't need to be. Note that the impact of this parameter is a work in progress

Control how the IG publisher does a comparison with a IPA (see qa.html). Possible values:

• {last} - compare with the last published version (whatever it's status) - this is the default if the parameter doesn't appear
• {current} - compare with the last full published version
• n/a - don't do any comparison
• [v] - a previous version where [v] is the version

Control how the IG publisher does a comparison with a IPS (see qa.html). Possible values:

• {last} - compare with the last published version (whatever it's status) - this is the default if the parameter doesn't appear
• {current} - compare with the last full published version
• n/a - don't do any comparison
• [v] - a previous version where [v] is the version

Whether to require that references in bundles resolve. true means references must resolve within implementation guides or an error is created.

String format to use when rendering date values from resources in the implementation guide.

String format to use when rendering date/time values from resources in the implementation guide.

Note: see Patterns for Formatting and Parsing for Java String formats

If set to true, it means that all profiles created within the implementation guide will have their differential modified to set maxOccurs=0 on all isModifier elements that are not explicitly mentioned in the original source differential.

How long to let Jekyll run before giving up on it (seconds)

A comma separated list of resource ids to suppress ids when they are rendered in the Implementation Guide.

This is useful because the IG publication process requires all resources to have ids, so they can be handled. But in some Implementation Guides, some examples should not have ids .e.g showing an example of posting a new resource. If the resource is listed here, the id will be removed in the publication (but not the package, where the resources must have ids). The format is either type/id, or just id. Repeating parameters just add more to the list. If the parameter is present with the special value $examples, then all examples will have ids suppressed If the parameter is not present, then all resources will have ids.

A boolean that indicates that the implementation guide leverages tabs to include alternate dictionary views and that tabs for differential, key and/or must-support tables should link to anchors specific to those tables rather than only to the default 'snapshot' keys.

If your IG is published via HL7 and should your package ID diverge from the file name in the JIRA-Spec-Artifacts repository, this parameter will help point to the right file.

For an R4B IG, ignore this profile when considering conversion to R4, or for an R4 IG, omit this when generating the R4 specific package. Value is either '{type}/{id}' or '{url}'

For an R4 IG, ignore this profile when considering conversion to R4B, or for an R4B IG, omit this when generating the R4B specific package. Value is either '{type}/{id}' or '{url}'

Produce the resources as .json in the jekyll _data folder. Note that Jekyll will fail if any of the resources contain non-ascii characters

Reference to a Page Factory

If true, causes the list of global profiles to appear at the top of the Artifacts Summary page

If true, causes the ig to not inject a root 'toc' page if that's not already the root (only functions in templates that do this by default)

If true, causes artifact pages to be created as children of the IG's 'root' page rather than the 'artifacts' page (if the template supports doing that)

Defines an additional version of the FHIR definitions to load for version conversion maps. Value is either RX or V.V (e.g. R4 or 4.0). Additional versions are loaded with modified URLs (e.g. R4 is loaded to http://hl7.org.fhir/4.0)

No Warning in QA if there are extensions/profiles that are not used in this IG

The default language (e.g. Resource.language) to assume in the IG when the resource and/or the element context doesn't specify a language

A language to translate the IG into. note that i18n-default-lang is automatically a language, and doesn't need to be restated

A folder in which to look for translation source files - .po or .xliff or .json

A folder in which to look for translation supplements - .po or .xliff or .json. This is deprecated - use translation-sources instead

Instruct the terminology layer that wrong displays result in a warning not an error. Note that you have to clear the terminology cache manually when changing the value of this parameter.

Whether to report issues when scanning files for resources. Valid values are: true, false, stack

An integer value that specifies the a number of seconds. If any resource takes longer than that time, it will be reported in the log

A ViewDefinition to execute (path to file). Output is added in the package.db file as a generated table, and can be used in the page contents. See also documentation

A code that indicates how to format fixed and pattern values. Valid values for this parameter are json | json-all | xml | all-xml. The -all options relate to primitives - whether they are shown just as a value or as a formatted fragment

Defines the OID root for the IG. Must be globally unique. Contact the FHIR product director or deputy for an assignment, though you can assign your own if you wish. If this is present, any canonical resources that do not have OIDs assigned manually will have OIDs automatically assigned by the publisher. The OID assignments are stored in oids.ini next to the IG resource for the IG, and must be committed with other changes to the source.