FHIR Chat · Forge 18.6 for STU3 (Colonia 2018 Edition)

Stream: implementers

Topic: Forge 18.6 for STU3 (Colonia 2018 Edition)

Michel Rutten (May 09 2018 at 14:06):

Forge 18.6 for STU3 (Colonia 2018 Edition) is now available for download from https://fire.ly/forge/.

This release is a major Forge update that introduces some new features and also contains a number of usability, stability, and performance improvements.

Change log: https://simplifier.net/organization/firely/news/48

If you find a new issue or would like to submit a feature request, please contact us at forge@fire.ly.

Or come and meet us in Cologne!

Satya Yelisetti (May 24 2018 at 09:59):

Hi @Michel Rutten ,
I can’t say if this is a bug but this new version of forge (Forge 18.6) is doing things which I would like to get to your notice.
I was doing a non-normative change which is just updating structuredefinition.title of a related person profile and expected GIT to detect only this particular change but many changes which I haven’t done have showed up like <element id="RelatedPerson.identifier:healthcarecard.system"> changed to <element id="RelatedPerson.identifier:healthcareCard.system">. The change here is the case of ‘C’ in healthcarecard.
So out of my curiosity I have started looking into other profiles as well. I found that if we just open and close the profile in forge doesn’t do anything but a small non-normative change like the one mentioned above is triggering it. I have attached a screenshot for you reference and would like to request to shed some light over this behaviour. Forge-18.6-Case-problem.png

Michel Rutten (May 28 2018 at 10:05):

Hi @Satya Yelisetti, correct, Forge has some special logic to support element ids. After some discussion with FHIR core team, we decided that it would be best for Forge to auto-generate element id values according to a predefined "canonical" format. The element id values are generated from element paths and slice names (if specified). Changing any (!) element property triggers Forge to re-generate the associated element id and the ids of all child elements.
In this case, it looks like the casing of the slice name was updated externally. As a result, the (previously generated) element id's were no longer in sync. Editing the profile caused Forge to re-synchronize the element id's from the actual, updated slicename.

Richard Townley-O'Neill (May 28 2018 at 22:56):

I find that the igpublisher changes
<element id="Patient.extension:closeTheGapRegistration"> to
<element id="Patient.extension:closethegapregistration">
It seems that the igpublisher is using a different format.
Any ideas when it will use camel case?

David McKillop (Jun 01 2018 at 06:06):

Hi @Michel Rutten , I'm not sure if the issue of Forge changing the labels from Resourcename.dataelement to Resource.dataelement eg "RelatedPerson.identifier" to "Resource.identifier" has been raised before, but the issue can be reproduced as follows:
If some text eg "Blah" is added to a descriptive field and saved, Forge gives a "Type" error- refer to the attached screen dump:
Type-error-20180601.JPG
What happens is that Forge changes the names of the label to "Resource.dataelement".
The file used before the Forge change is :
relatedperson-dh-base-before.xml
The file after "Blah" has been added to the text field and saved is:
relatedperson-dh-base-after.xml
If you need any further information/clarification, please be in touch.
Cheers
D. Mc

Michel Rutten (Jun 04 2018 at 09:16):

Hi @David McKillop, thank you for reporting this regression introduced in the 18.6 release. We have already fixed the issue in the development branch and are planning to publish an update this week.

Richard Townley-O'Neill (Jun 04 2018 at 22:31):

@Grahame Grieve
I find that the igpublisher changes
<element id="Patient.extension:closeTheGapRegistration"> to
<element id="Patient.extension:closethegapregistration">
It seems that Forge is using a different format.
Any ideas when the igpublisher will preserve camel case?

Grahame Grieve (Jun 04 2018 at 23:31):

I don't know why it would be changing that

Richard Townley-O'Neill (Jun 04 2018 at 23:45):

I'm using FHIR Implementation Guide Publisher (v3.4.0-13755, gen-code v3.4.0-13690)
Do you want to see any examples?

Grahame Grieve (Jun 04 2018 at 23:50):

yes

Richard Townley-O'Neill (Jun 04 2018 at 23:54):

input resource file au-composition.xml
generated file StructureDefinition-au-composition.xml

Richard Townley-O'Neill (Jun 05 2018 at 00:03):

Michel Rutten (Jun 05 2018 at 09:13):

Hi @Richard Townley-O'Neill, FYI Forge generates element ids based on the element paths and (optional) slice names, preserving the original character casing.

Richard Townley-O'Neill (Jun 05 2018 at 23:08):

@Michel Rutten Thanks. From your post on 28 May I believe that Forge is behaving correctly and it is the igpublisher that is doing something different. I do not know whether this will cause problems, other than lists of unimportant changes when working on files with both tools.

Michel Rutten (Jun 06 2018 at 10:02):

Hi @Richard Townley-O'Neill, technically, FHIR provides a default format to generate element ids, based on path and slicename, but (as far as I am aware) this format is not mandatory. The popular reference tools all implement the default format. Most importantly, you have to ensure that element references are kept in sync with the actual element ids. If you deviate from the default format, this might be harder to achieve/guarantee.