Stream: shorthand
Topic: Binary Adjunct
John Moehrke (May 24 2021 at 17:59):
Does Shorthand have support for the IG Publisher feature of Binary Adjunct files? https://confluence.hl7.org/pages/viewpage.action?pageId=66938614#ImplementationGuideParameters-BinaryAdjunctFiles
Chris Moesel (May 24 2021 at 20:45):
Since this is a feature of the IG Publisher, I don't think there is anything special that FSH/SUSHI have to do in that case. You should be able to use FSH to set the attachment id to any arbitrary string, so setting it to "ig-loader-[filename]" should work just fine. And then the IG Publisher picks it up from there. Is there something special you would expect (or want) FSH/SUSHI to do here?
John Moehrke (May 25 2021 at 10:13):
Given where the FSH files are, the processing of them by sushi, where they get stuffed, how the IG json gets written, ... I figured I would ask if there was a similar feature, or if I needed to hack my way to using this without making sushi angry.
Chris Moesel (May 25 2021 at 12:43):
Hi @John Moehrke. Hopefully there is not too much hacking involved! I just decided to try this myself and got it working with a CQL library. To do that, I had to:
- Add the following to my
sushi-config.yamlto identify where "binary" files can be found:
parameters:
path-binary: input/cql
- Create the
input/cqlfolder and put my CQL file in it. For this test, I used a simple CQL file namedHelloWorld.cql:
library HelloWorld version '0.1.0'
using FHIR version '4.0.1'
define Message: 'Hello World!'
- Create the following instance in FSH (I put it in
input/fsh/libraries.fshbut any file ininput/fshshould do):
Instance: HelloWorld
InstanceOf: Library
* name = "HelloWorld"
* url = "http://example.org/Library/HelloWorld"
* status = #draft
* type = http://terminology.hl7.org/CodeSystem/library-type#logic-library
* content.id = "ig-loader-HelloWorld.cql"
The key is the line w/ content.id. I also learned (the hard way) that if you define any other properties under content it will not work. It must have the id only!
- Run SUSHI to ensure I didn't make any mistakes in the FSH.
- Run
_genonce.shto run the IG Publisher.
That seemed to do the trick!
Chris Moesel (May 25 2021 at 12:46):
BUT... I also discovered that there is an issue when attempting to do this w/ the Binary resource. Since the Binary resource doesn't use Attachment, you must set the special string "ig-loader-[filename]" directly on the data element. When you do this, however, SUSHI issues an error because it knows that data should be a base64-encoded string, and it recognizes that "ig-loader-[filename]" is not valid base64 content. So... we'll need to update SUSHI to support this special case for Binary.
John Moehrke (May 25 2021 at 12:51):
ill try. I need this alot in the IHE MHD profile for the examples.
John Silva (May 25 2021 at 13:02):
Not sure if this is a similar use case ... We have our Library resources populated by FSH with:
"content": [
{
"id": "ig-loader-FHIRHelpers.cql",
"contentType": "text/cql"
},
{
"id": "ig-loader-FHIRHelpers.elm",
"contentType": "application/elm+json"
}
Then we post-process the FSH-generated Library JSON files to add the base64 versions of the referenced files, both CQL and ELM, and add them as the .data element to each entry in the content[] array. Because of the naming convention pointed out earlier, and the fact that we know where these cql and elm files are located (relative to the FSH output dirs) we can do this in our scripting. It would be nice to not have to have a separate post-processing script to do this though. :-)
Chris Moesel (May 25 2021 at 13:15):
@John Silva -- the binary adjunct loading that John M linked to above should take care of these things for you. You should not need to maintain your own separate script for that. Try removing the contentType from the FSH for the libraries (so only id remains) and making sure you've appropriately configured the path-binary parameter to point to wherever you have your CQL (inside the IG folder structure).
Chris Moesel (May 25 2021 at 13:16):
Oh. Also remove the content entry for the .elm. You should also get that for free from the IG Publisher. (And do note, these features are provided by the IG Publisher, not SUSHI).
Chris Moesel (May 25 2021 at 13:46):
I've logged the SUSHI issue w/ the Binary resource as SUSHI #819.
John Silva (May 25 2021 at 14:14):
@Chris Moesel - thanks. We haven't used the IG Publisher though, only SUSHI. I'll have to look into this more to figure out how to do this or to let IG Publisher do this for us. (Our CQL execution logic expects the cql+elm base64 encoded content in the Library resources.)
John Moehrke (Dec 31 2021 at 14:47):
@Chris Moesel did you get a contentType working? I understand from Grahame that I need to add the implementationguide-resource-format extension to define these.. but I tried to add that in the sushi-config.yaml but it didn't end up in the fsh-generated IG
John Moehrke (Dec 31 2021 at 14:49):
this extension is in the sushi release notes associated with a feature for logical models. (I can't find any other mention of this extension, including in the IG documentation)
Chris Moesel (Jan 03 2022 at 14:37):
@John Moehrke - no, I did not get it working, but I had not tried it any further after that discussion with you. If you define an extension in the sushi-config.yaml, it should go through to the fsh-generated IG JSON. I'll have to take a look.
John Moehrke (Jan 03 2022 at 14:39):
okay. No hurry. It does fully work fine with DocumentReference, just not with Binary. I think the Binary is the one that needs the extension, but I am not sure.
Last updated: Apr 12 2022 at 19:14 UTC
