Implementation Guide Parameters

The parameters are now documented in two places:

• Parameters defined by core FHIR: http://build.fhir.org/codesystem-guide-parameter-code.html
• Parameters defined by the FHIR Tools IG: http://build.fhir.org/ig/FHIR/fhir-tools-ig/branches/master/CodeSystem-ig-parameters.html

note that those are the parameters that go in the IG parameter (or sushi-config.yaml). For the command line parameters of the IG publisher command line tool, see IG Publisher CLI

Managing Warnings and Hints

The implementation guide publisher generates many Warnings and information messages. They may arise from:

• Errors in the design of the Implementation Guide
• Bugs in the publication tooling
• Necessary outcomes from the specification (not an issue at all)

Every one of these messages needs to be checked. When there are a large number of these, it can be difficult for someone reviewing the qa page to distinguish which warnings they need to pay attention to and which are new/important. Once the message has been checked and is known to be not an issue needing resolution, the message can be added to the suppressed warnings file (usually ignoreWarnings.txt). 

This file has the following format:

== Suppressed Messages ==

# Your Reason Here
error or warning message to be suppressed
error or warning message to be suppressed
...

Lines are grouped by # Reason which explains why the message is considered ok (not an error).  Each message line below it contains the message to be suppressed - copy and paste the message from the qa.txt file produced by the ig-publisher. (typically output/qa.txt). 

The text is matched by doing a case insensitive comparison. You can use % at the start and/or end of the message to do a partial comparison. You can also provide the internal ID of the message instead of the text to suppress all messages of a particular class (the internal ID is shown in the qa file)

Example:

== Suppressed Messages ==

# The following code systems are external and not supported by terminology server
Code System URI 'http://www.ama-assn.org/go/cpt' is unknown so the code cannot be validated
# example for suppressing information messages
Code System URI "http://example.org" is unknown so the code cannot be validated

This mechanism can suppress information messages, warning messages and errors related to broken links (e.g. if a link is created to a file produced during post-processing or that otherwise isn't resolvable during the IG publication process).

Binary Adjunct Files

For several resource types, it can be more convenient to edit base64Binary content directly. The obvious candidate resources are:

• Binary
• Library
• DocumentReference 

But there are many other resources where this might be useful. The technique described here will work for any Resource with Attachments in it.

Here's how to make it work: 

• Create the resource as per normal 
• For the attachment resource, leave it empty, and provide only an id and contentType
• the id has the special value "ig-loader-[filename]", where filename is the name of the file to load. e.g. "id" : "ig-loader-MyLibrary.cql"  (case sensitive)
• The IG Publisher will scan all the folders identified by the path-binary parameter (see above), and remove the id property, and replace with with the content from the file 
• If a matching file cannot be found, the id will be left in place, and an error will be logged in the qa page

Binary is a special case. For Binary, make the content of the data itself equal to "ig-loader-[filename]"

Note: the following file extensions are supported:

• .txt (text/plain)
• .pdf (application/pdf)
• .jpg, .png, .gif (image/xx)
• .dicom - application/dicom
• .cql - text/cql. Note that CQL included into a library is subject to additional processing. A second content will be injected for application/elm+xml - do not create a stub for this manually)