Stream: shorthand
Topic: ig-loader examples
John Moehrke (Dec 10 2021 at 19:05):
Does someone have a working use of "ig-loader" Binary adjunct files support? I am reading the documentation and not grok
https://confluence.hl7.org/pages/viewpage.action?pageId=66938614#ImplementationGuideParameters-BinaryAdjunctFiles
John Moehrke (Dec 14 2021 at 13:46):
I would like to use this ig-loader functionality, but I can't get it to work.
Chris Moesel (Dec 14 2021 at 14:02):
I feel like I tried this once before. I will check to see if I still have that example lying around somewhere.
Chris Moesel (Dec 14 2021 at 14:40):
OK. I found it and experimented some more. When I use it w/ CQL (which includes special behavior to also compile to ELM), it works well. When I use it w/ a JPG, it causes errors. But... it does seem to populate the base64 data anyway (although I thought it would also populate contentType, which doesn't seem to be happening).
Here's my sample project: BinaryAdjunct.zip
John Moehrke (Dec 15 2021 at 20:21):
I tried it with .txt files. It did not appear to put the file into the DocumentReference.content
John Moehrke (Dec 15 2021 at 20:32):
@Jose Costa Teixeira have you used ig-loader to load binary?
John Moehrke (Dec 15 2021 at 20:53):
I just got it to work with Binary and a jpg file... (my own fat fingers typo to blame).
John Moehrke (Dec 15 2021 at 21:03):
do notice that in DocumentReference. It will work, but will not set the contentType, and if you try to set the contentType, the the ig-loader solution will not work (just puts the ig-loader filename on the id). I think this is the first problem I was noticing. So, this works
Instance: Dr-SAML-QDI
InstanceOf: DocumentReference
* status = #current
* content.attachment.id = "ig-loader-QDI-SAML-20211210.jpg"
but will not give you a DocumentReference with a contentType.
If you add contentType, then you will not get what you want.
John Moehrke (Dec 15 2021 at 21:16):
And as @Chris Moesel mentions two errors do show up in the QA report
att-1: 'If the Attachment has data, it SHALL have a contentType' Rule 'If the Attachment has data, it SHALL have a contentType' Failed
and
Unknown file type foobar.txt
John Moehrke (Dec 15 2021 at 21:34):
so, is this a problem in sushi support for ig-loader? Or is this a problem in IG builder? or both? ... meaning, where should I log an issue?
Chris Moesel (Dec 16 2021 at 14:03):
I believe it's in the IG Publisher. SUSHI doesn't do anything special for adjunct binary. It's just another instance from SUSHI's point of view. All of the magic is in IG Publisher.
Chris Moesel (Dec 16 2021 at 14:07):
That said, the one thing SUSHI could potentially improve here is its treatment of Binary when the data field starts w/ ig-loader-. Since SUSHI treats it like a normal instance, it emits an error if you don't specify contentType (since it is 1..1), but if the IG Publisher populates contentType for adjunct binaries, then SUSHI could potentially detect that the data value starts with ig-loader- and then relax the cardinality check... but I don't think that would fix the issue you see here.
John Moehrke (Dec 16 2021 at 14:20):
that seems right. I will record as ig-publisher bug.
John Moehrke (Dec 16 2021 at 14:45):
https://github.com/HL7/fhir-ig-publisher/issues/355
Last updated: Apr 12 2022 at 19:14 UTC
