Stream: implementers
Topic: add a condition on an element for a defined constraint
Vikas Mittal (Sep 19 2019 at 06:22):
There are a few FHIRPath invariants, defined on various elements of a profile.
Some of those invariants/constraints restricts the elements present downward in the hierarchy.
e.g. an invariant having the key "inv-1" defined on the Patient element having expression "name.exists() or identifier.exists()" involves three elements: Patient, name and identifier.
I want the (I) Flag to appear on each of the three elements above, in both the Differential or Snapshot views of the Patient profile.
This page http://hl7.org/fhir/R4/formats.html#table states this about the (I) flag ---> I: This element defines or is affected by constraints
I am using Firely Forge and IG Publisher to edit the profile and generate the IG, but the results are mostly inconsistent and incorrect.
In most of the cases the xml fragment added is like this: <condition value="invariant-key" />
e.g.
<StructureDefinition xmlns="http://hl7.org/fhir">
.
.
.
<differential>
<element id="Patient">
<path value="Patient" />
<constraint>
<key value="inv-1" />
<severity value="error" />
<human value="The patient must have a name or an identifer" />
<expression value="name.exists() or identifier.exists" />
</constraint>
</element>
.
.
.
<element id="Patient.identifier">
<path value="Patient.identifier" />
<condition value="inv-1" />
</element>
<element id="Patient.name">
<path value="Patient.name" />
<condition value="inv-1" />
</element>
.
.
.
</differential>
</StructureDefinition>
Just wanted to know if anyone has tested doing it before and have they got the intended results?
Grahame Grieve (Sep 19 2019 at 09:14):
you have an example?
Vikas Mittal (Sep 20 2019 at 07:18):
Hi @Grahame Grieve
I have tried to re-create the issue I faced working on the Agency profiles, using the HL7AU (FHIR R4) Practitioner profile.
The link of the profile I have used is -- http://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-au-practitioner.html
GitHub link --- https://github.com/hl7au/au-fhir-base/blob/master/resources/au-practitioner.xml
This is the copy of the profile that currently exists -- au-practitioner.xml.
Then I added the following five conditions on the relevant elements using Forge.
<condition value="inv-hpii-0" />
<condition value="inv-hpii-1" />
<condition value="inv-hpii-2" />
<condition value="inv-caei-0" />
<condition value="inv-ahpra-1" />
A copy of the modified file is here --- au-practitioner-conditions-only.xml
The "Differential Table" shows the (I) Flag as expected, on the elements the condition is added on. Screenshot here --- pasted image
But the "Snapshot Table" does not! Screenshot here --- pasted image
Also the "Detailed Descriptions" Tab does not have the text which
- either says "This element is affected by the following invariants: <inv-key>"
- or probably something similar to this as shown in this screenshot --- pasted image
Please let me know in case I have missed anything or I am still not very clear.
PS: I have deliberately not added the queries about the au-practitioner profile the Forge Tool generated, when I added the 5 conditions, as that would potentially add to confusion.
Michel Rutten (Sep 20 2019 at 09:20):
Seems like a rendering error? I would expect the rendering logic to pick up and display your constraints & conditions.
Grahame Grieve (Sep 23 2019 at 21:08):
fixed next release
Vikas Mittal (Sep 24 2019 at 03:02):
Thanks @Grahame Grieve
Vikas Mittal (Sep 24 2019 at 03:21):
Hi @Michel Rutten, just a query in relation to this. (Not sure if this is the right place to raise it. Please advise if you think a separate topic in another stream will be preferable)
As described above I used this au-practitioner profile to add Invariant Flag conditions, a copy of which is here --- au-practitioner.xml
I opened this file in Forge and added only these five conditions, without changing anything else and then saved it.
<condition value="inv-hpii-0" />
<condition value="inv-hpii-1" />
<condition value="inv-hpii-2" />
<condition value="inv-caei-0" />
<condition value="inv-ahpra-1" />
The resultant file I got is this --- au-practitioner-forge-default.xml
In this file you can see that the Forge tool added <source/> tags and removed some of the xml code!
Just wanted to know is it the correct behaviour from the tool?
An outcome of the Forge tool adding the <source/> element is that the constraint key and the constraint human value "goes missing" from the Differential and Snapshot Tables in the profile generated by IGPublisher!
Michel Rutten (Sep 25 2019 at 10:47):
Hi @Vikas Mittal, Forge re-generates the StructureDefinition.differential component by excluding all inherited constraints, as specified by the base profile and element type profiles (if any). A decrease in size of the differential component indicates that Forge removed some redundant constraints.
The ElementDefinition.constraint.source field was introduced in FHIR R4. Forge R4 automatically generates this field value in the snapshot component, as specified by the spec:
http://hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.constraint.source
Michel Rutten (Sep 25 2019 at 10:48):
I don't know why the IG Publisher stumbles on this field. Maybe you discovered a bug in the rendering code?
Grahame Grieve (Sep 25 2019 at 11:16):
the java snapshot generator was missing ElementDefinition.condition. I fixed that today
Vikas Mittal (Sep 25 2019 at 11:50):
Thanks @Michel Rutten and @Grahame Grieve
I will test it with the latest IG Publisher and get back to you in case it's required further.
Vikas Mittal (Sep 30 2019 at 00:14):
Thanks @Grahame Grieve
I have tested it with FHIR IG Publisher (Version 0.9.82-SNAPSHOT - Built 2019-09-24T07:48:38.927+10:00 - Git 7c7c6916f395)
It has now fixed the rendering issue for the (I) Flag,in both the Snapshot Table and the Detailed Descriptions tabs.
The other rendering issue still remains where, constraint key and the constraint human value goes missing from the Differential and Snapshot Tables in the profile.
Grahame Grieve (Oct 18 2019 at 03:27):
@Vikas Mittal is this still a problem? If so, how do I reproduce it?
Vikas Mittal (Oct 18 2019 at 04:51):
Yes @Grahame Grieve it is still an issue.
To reproduce you can either
.
clone https://github.com/hl7au/au-fhir-base.git repository and open this file (https://github.com/hl7au/au-fhir-base/blob/master/resources/au-practitioner.xml) in the Forge R4 tool. Then add a condition (<condition value="inv-hpii-0" />) and save it. The file generated by the Forge tool now adds this (<source value="Practitioner" />). If you run the IG Publisher on HL7AU and the resulting page of au-practitioner will have missing constraint keys and constraint human values.
.
OR
.
you can just replace the au-practitioner.xml file in the https://github.com/hl7au/au-fhir-base.git cloned repository with this file (au-practitioner.xml) and then run the IG Publisher setup .
Please let me know if you want me to create and send you the setup as a branch of some repository.
Grahame Grieve (Oct 25 2019 at 00:07):
the file you provided is identical?
Vikas Mittal (Oct 25 2019 at 01:15):
Yes @Grahame Grieve
I took this file (https://github.com/hl7au/au-fhir-base/blob/master/resources/au-practitioner.xml) and edited it using the Forge tool.
The resultant file (https://chat.fhir.org/user_uploads/10155/4pZGOFkccgiXsBV6jiBXvRnn/au-practitioner.xml) that the Forge tool generated, is the file that I have provided in my previous comment.
And that is the file that the IG Publisher is having rendering issues with.
.
While the current file on the github (https://github.com/hl7au/au-fhir-base/blob/master/resources/au-practitioner.xml) does not have those rendering issues.
Grahame Grieve (Oct 25 2019 at 05:11):
So the problem is that the invariants are not rendered like this:
Grahame Grieve (Oct 25 2019 at 05:12):
Grahame Grieve (Oct 25 2019 at 05:13):
That results from a decision by the IG creation stream to not render constraints that come from inherited models. So to get your constraints to render, remove the "source" statement on them
Vikas Mittal (Oct 25 2019 at 06:10):
Thanks @Grahame Grieve
@Michel Rutten do you think it is okay for the Forge to add the <source/> tags when I am "editing an existing profile" and not "deriving and creating a new profile"?
Michel Rutten (Oct 25 2019 at 08:39):
Forge R4 contains some basic logic to ensure that .constraint.source fields are initialized. The description of the field mentions rendering, but remains a bit vague. I was waiting for some feedback/guidance from the community about this aspect.
@Grahame Grieve I guess that rendering logic could also determine if a constraint is introduced or inherited by inspecting the source; if source points to the containing resource, then the constraint is introduced, not inherited? (similar to ElementDefinition.base.path)
Grahame Grieve (Oct 25 2019 at 20:52):
well, that's the intent. What we're doing is leaving it blank when it's defined in this structure definition, and populating it otherwise. but I see that we're not populating it correctly - it should be the canonical URL of the source
Dusica Bojicic (Dec 03 2019 at 22:30):
@Michel Rutten, is Forge R4 change to stop initializing ElementDefinition.constraint.source in plan?
Russell Buchanan (Dec 15 2019 at 16:20):
@Michel Rutten, we have been testing use of Forge R4 as part of the Canadian Baseline Profiling effort. As noted by Vikas above, Forge adds .constraint.source whenever we edit and save a profile that introduces constraints. This causes the constraints to fail to render in the IG Publisher output. Is there a plan to change this?
Ward Weistra (Dec 16 2019 at 16:48):
Hey @Dusica Bojicic and @Russell Buchanan, thanks for mentioning that! It seems it is valid FHIR to fill that field, but the Publisher doesn't accept it?
@Grahame Grieve would this then be something to fix in the IG Publisher instead?
Grahame Grieve (Dec 16 2019 at 19:42):
I think that Forge is populating it wrongly. the renderer does not publish the constraint if the source indicates it comes from some inherited model (the profiles are littered with inherited constraints). So if the source is empty, or doesn't match the current canonical, then it doesn't get rendered. From memory, forge isn't putting a canonical in there?
Dusica Bojicic (Dec 16 2019 at 20:54):
@Grahame Grieve, Forge does not put the canonical, I think it populates the field with the resource name. IG Publisher does not render constraints either when the source is populated with the current canonical (unless that changed in the last 10 days or so).
Grahame Grieve (Dec 16 2019 at 21:02):
you're right. I thought I had fixed that. Next release will allow source = self
Richard Townley-O'Neill (Dec 17 2019 at 06:59):
It doesn't work in v 1.0.24 of the igPublisher.
Ward Weistra (Dec 17 2019 at 09:44):
OK thanks @Grahame Grieve @Dusica Bojicic. Based on the above I understand Forge is behaving correctly. Please correct me if I'm wrong!
Grahame Grieve (Dec 17 2019 at 09:45):
no. it needs to populate the source with the canonical URL, not the name
Alexander Zautke (Dec 17 2019 at 10:00):
@Ward Weistra @Marten Smits found the same issue independently. Bug report can be found here: https://github.com/FirelyTeam/fhir-net-api/issues/1188
Ward Weistra (Dec 17 2019 at 10:06):
Ah wonderful, and it's already planned for the upcoming API sprint. Once it's included there we'll add it to Forge!
Right now we're planning a January release of Forge, but the API release might not be out yet by then. So probably the next release after that. cc @Dusica Bojicic @Russell Buchanan Sorry for the inconvenience until then.
Last updated: Apr 12 2022 at 19:14 UTC
