Stream: implementers
Topic: IG publisher and extensions
Richard Townley-O'Neill (Oct 25 2017 at 00:47):
It seems that there are two places to specify the multiplicity range for an extension, in the StructureDefinition for extension itself and in the SD for the resource that uses the extension.
In a SD I used both options (accident) and Forge and the igPublisher processed it differently. Which is correct?
Here is the example. I've defined a resource (Consent) that uses three extensions (Date, Decision and Provision). It specifies 1..1 of the second extension (Decision) and says nothing about the multiplicity range of the others. The SD for the first extension (Date) says that it is 1..1, the SDs of the second and third say nothing about their multiplicity.
Consent
-extension - Date (1..1)
-extension (1..1) - Decision
-extension - Provision
Forge shows for Consent a multiplicity range for Date and Decision of 1..1, Provision is 0..* .
The igPublisher produces hierarchies for Consent with a multiplicity range for Date of 0..* , for Decision of 1..1, and Provision is 0..* .
Is this expected behaviour?
Lloyd McKenzie (Oct 25 2017 at 03:13):
What's supposed to happen is that when an extension is referenced inside of a resource profile, the cardinality should be the same as or tighter than the root element of the extension definition. So if the Extension is defined as 0..1, it's illegal for it to be referenced in a profile as 0..*.
Richard Townley-O'Neill (Oct 25 2017 at 04:16):
In the extension, Date, it is 1..1. The profile, Consent, says nothing about the cardinality range for Date. It has not expressly contradicted the extension.
However, the data hierarchy produced by the igPublisher shows 0..* .
Richard Townley-O'Neill (Oct 25 2017 at 04:17):
Has anyone else noticed this?
Grahame Grieve (Oct 25 2017 at 04:21):
can you make a task and I'll investigate next week
Richard Townley-O'Neill (Oct 25 2017 at 04:35):
#14090
Do you want any of the files that I'm using?
Richard Townley-O'Neill (Oct 25 2017 at 06:30):
I raised another ig query in #4091
It is about changes to element ids in StructureDefinition files.
Richard Townley-O'Neill (Nov 02 2017 at 04:04):
@Grahame Grieve
any progress?
Richard Townley-O'Neill (Nov 06 2017 at 00:48):
Has anyone else noticed the igPublisher doing the following?
It has replaced "Immunization.explanation.reasonNotGiven" with "Immunization.reportOrigin.reasonNotGiven"
This in a file in the resource folder
<element id="Immunization.reportOrigin">
<path value="Immunization.reportOrigin" />
<min value="1" />
<fixedCodeableConcept>
<text value="Australian Immunisation Register" />
</fixedCodeableConcept>
</element>
<element id="Immunization.explanation.reasonNotGiven">
<path value="Immunization.explanation.reasonNotGiven" />
This in the produced file in the output folder
<element id="Immunization.reportOrigin">
<path value="Immunization.reportOrigin"/>
<min value="1"/>
<fixedCodeableConcept>
<text value="Australian Immunisation Register"/>
</fixedCodeableConcept>
</element>
<element id="Immunization.reportOrigin.reasonNotGiven">
<path value="Immunization.explanation.reasonNotGiven"/>
I've raised the issue #14091
Christopher Schuler (Nov 06 2017 at 01:47):
Looks like this issue was answered by @Lloyd McKenzie in that issue you posted. I am pretty sure what he is saying is that you need <element id="Immunization.explanation> specified before you can have <element id="Immunization.explanation.reasonNotGiven">. Otherwise the publisher will replace that with the last occurring element id. Does that make sense? Please correct me if I am wrong Lloyd.
Richard Townley-O'Neill (Nov 06 2017 at 03:27):
I had not realised that from Lloyds previous post. Is that expected behaviour, or just a limitation of the igPublisher?
Grahame Grieve (Nov 06 2017 at 03:28):
it would be a bug in the IGpublisher
Richard Townley-O'Neill (Nov 06 2017 at 03:29):
Nice to know. Now I can work around it.
Last updated: Apr 12 2022 at 19:14 UTC
