FHIR Chat · slicing sliced extension · IG creation

Stream: IG creation

Topic: slicing sliced extension

John Moehrke (Dec 06 2021 at 13:24):

I have explained a slicing problem I am having over on the sushi stream
https://chat.fhir.org/#narrow/stream/215610-shorthand/topic/slicing.20an.20extension.20on.20a.20slice
I started on the sushi stream because I initially was worried I was not using sushi right.
I am not having trouble with sushi, but rather the validation in the IG build.
Specifically my examples are failing validation, but I have checked the error message and looked at the JSON created by sushi. I can't figure out what I have done wrong.

Slicing cannot be evaluated: Could not match discriminator ([url]) for slice AuditEvent.agent:user.extension:otherId/subject-id in profile http://profiles.ihe.net/ITI/BasicAudit/StructureDefinition/ITI.BasicAudit.SAMLaccessTokenUse.Comprehensive.Norway - the discriminator [url] does not have fixed value, binding or existence assertions

my github repo - https://github.com/IHE/ITI.BasicAudit

John Moehrke (Dec 06 2021 at 13:26):

the specifics of the error

- the discriminator [url] does not have fixed value, binding or existence assertions

Yet, I definitely have a fixed code in my example

        {
          "url" : "http://profiles.ihe.net/ITI/BasicAudit/StructureDefinition/ihe-otherId",
          "valueReference" : {
            "identifier" : {
              "type" : {
                "coding" : [
                  {
                    "system" : "http://profiles.ihe.net/ITI/BasicAudit/CodeSystem/OtherIdentifierTypes",
                    "code" : "SAML-subject-id"
                  }
                ]
              },
              "value" : "JohnDoe"
            }
          }

Lloyd McKenzie (Dec 06 2021 at 14:26):

It's not complaining about the example, it's complaining about the profile.

John Moehrke (Dec 06 2021 at 14:47):

I seek only to make IG builder happy... so, what ever it takes

Lloyd McKenzie (Dec 06 2021 at 15:24):

Check the profile for fixed values for the URL.

John Moehrke (Dec 06 2021 at 19:21):

im not sure which URL is in question. Here is the fragment from the JSON created by sushi

      {
        "id" : "AuditEvent.agent:user.extension:otherId/subject-id",
        "path" : "AuditEvent.agent.extension",
        "sliceName" : "otherId/subject-id",
        "short" : "Extension",

is that "id" what is being refered to as a URL?

John Moehrke (Dec 06 2021 at 19:23):

Here is the Profile that this error is coming from
http://build.fhir.org/ig/IHE/ITI.BasicAudit/branches/main/StructureDefinition-ITI.BasicAudit.SAMLaccessTokenUse.Comprehensive.html

John Moehrke (Dec 06 2021 at 19:29):

Im getting lots of similar errors. so I fully expect I am not doing something right. but others are indicating that my sushi seems to be written rigtht... so I thus want to dig deeper into the json that sushi creates to see if it is not doing something right.

Chris Moesel (Dec 06 2021 at 20:09):

I'll take a look at it as well to see if anything jumps out at me.

Chris Moesel (Dec 06 2021 at 20:16):

It looks to me like it might be an issue with the snapshot generator. Here's what we have in the differential for the otherId extension element and its subject-id reslice:

      {
        "id" : "AuditEvent.agent:user.extension:otherId",
        "path" : "AuditEvent.agent.extension",
        "sliceName" : "otherId",
        "slicing" : {
          "discriminator" : [
            {
              "type" : "pattern",
              "path" : "valueReference.identifier.type"
            }
          ],
          "rules" : "open"
        },
        "min" : 0,
        "max" : "*",
        "type" : [
          {
            "code" : "Extension",
            "profile" : [
              "http://profiles.ihe.net/ITI/BasicAudit/StructureDefinition/ihe-otherId"
            ]
          }
        ],
        "mustSupport" : true
      },
      {
        "id" : "AuditEvent.agent:user.extension:otherId/subject-id",
        "path" : "AuditEvent.agent.extension",
        "sliceName" : "otherId/subject-id",
        "min" : 0,
        "max" : "1"
      }

(Note that for brevity I've left out the elements that set the value reference)

Chris Moesel (Dec 06 2021 at 20:21):

But when the snapshot gets generated, the subject-id reslice gets the plain Extension type instead of the http://profiles.ihe.net/ITI/BasicAudit/StructureDefinition/ihe-otherId extension type it should be inheriting from the slice base:

    {
        "id" : "AuditEvent.agent:user.extension:otherId/subject-id",
        "path" : "AuditEvent.agent.extension",
        "sliceName" : "otherId/subject-id",
        "short" : "Extension",
        "definition" : "An Extension",
        "min" : 0,
        "max" : "1",
        "base" : {
          "path" : "Element.extension",
          "min" : 0,
          "max" : "*"
        },
        "type" : [
          {
            "code" : "Extension"
          }
        ],
        "constraint" : [
          {
            "key" : "ele-1",
            "severity" : "error",
            "human" : "All FHIR elements must have a @value or children",
            "expression" : "hasValue() or (children().count() > id.count())",
            "xpath" : "@value|f:*|h:div",
            "source" : "http://hl7.org/fhir/StructureDefinition/Element"
          },
          {
            "key" : "ext-1",
            "severity" : "error",
            "human" : "Must have either extensions or value[x], not both",
            "expression" : "extension.exists() != value.exists()",
            "xpath" : "exists(f:extension)!=exists(f:*[starts-with(local-name(.), \"value\")])",
            "source" : "http://hl7.org/fhir/StructureDefinition/Extension"
          }
        ],
        "isModifier" : false,
        "isSummary" : false
      }

Furthermore, when the snapshot drills into the subject-id reslice, it doesn't fix the uri in the AuditEvent.agent:user.extension:otherId/subject-id.url element, presumably because it is creating those elements based off Extension when it should be creating them based off the elements in the http://profiles.ihe.net/ITI/BasicAudit/StructureDefinition/ihe-otherId extension.

@Grahame Grieve - is this a known limitation of the snapshot generator?

Chris Moesel (Dec 06 2021 at 20:24):

BTW -- I also agree w/ what @Jean Duteau noted in the corresponding thread in the #shorthand channel, which is that the discriminator also needs to be updated to value.identifier.type or (value as Reference).identifier.type since valueReference is not a valid path in FHIRPath.

John Moehrke (Dec 06 2021 at 20:32):

Chris Moesel said:

BTW -- I also agree w/ what Jean Duteau noted in the corresponding thread in the #shorthand channel, which is that the discriminator also needs to be updated to value.identifier.type or (value as Reference).identifier.type since valueReference is not a valid path in FHIRPath.

I can try, sushi does not like either of those suggestions.

John Moehrke (Dec 06 2021 at 20:34):

this is what I have

* agent[user].extension[otherId][subject-id].valueReference.identifier.type = OtherIdentifierTypes#SAML-subject-id

what do you recommend I try?

Chris Moesel (Dec 06 2021 at 20:38):

@John Moehrke -- I'm talking about the discriminator path only. E.g., you probably have some FSH something like this:

* agent[user].extension[otherId] ^slicing.discriminator.path = "valueReference.identifier.type"

But that needs to be this:

* agent[user].extension[otherId] ^slicing.discriminator.path = "value.identifier.type"

or this:

* agent[user].extension[otherId] ^slicing.discriminator.path = "(value as Reference).identifier.type"

John Moehrke (Dec 06 2021 at 20:41):

ah, I tried the second, and sushi passed. Ill run that thru

John Moehrke (Dec 06 2021 at 20:48):

that built, but did not change the result

John Moehrke (Dec 06 2021 at 20:53):

I do have a more simple one that is equally failing. This one is not doing anything with an extension. it is just slicing a slice. The first slice defines .entity[consent]; this second slice within that first one.. This is also just a #value slice on a less deep .type element.

* entity[consent].detail ^slicing.discriminator.type = #value
* entity[consent].detail ^slicing.discriminator.path = "type"
* entity[consent].detail ^slicing.rules = #open
* entity[consent].detail contains
    acp 0..1 and
    patient-id 0..1
* entity[consent].detail[acp].type = "urn:ihe:iti:xua:2012:acp"
* entity[consent].detail[acp].valueString 1..1 MS
* entity[consent].detail[acp].valueString ^short = "Home Community ID where the Consent is."
* entity[consent].detail[patient-id].type = "urn:oasis:names:tc:xacml:2.0:resource:resource-id"
* entity[consent].detail[patient-id].valueString 1..1 MS
* entity[consent].detail[patient-id].valueString ^short = "The Patient Identity where the Consent is."

Chris Moesel (Dec 06 2021 at 20:59):

Ah... that last one might be due to a mismatch between the discriminator type and the type of fixed value (pattern vs fixed). If the discriminator type is #value, then you should put (exactly) at the end of the assignment rule for the path being discriminated on. E.g.:

* entity[consent].detail[acp].type = "urn:ihe:iti:xua:2012:acp" (exactly)
// ...
* entity[consent].detail[patient-id].type = "urn:oasis:names:tc:xacml:2.0:resource:resource-id" (exactly)

Or you can leave those as-is and change the discriminator type to #pattern.

John Moehrke (Dec 06 2021 at 21:10):

note that in this case .type is a datatype string

Chris Moesel (Dec 06 2021 at 21:19):

Yep. String datatypes can use pattern too since string also allows for id and extension sub-elements.

John Moehrke (Dec 06 2021 at 21:25):

well, that didn't change any results.

John Moehrke (Dec 06 2021 at 21:29):

so, clarification.. the slicing I have on .entity is not throwing the same errors... sorry. (different problem, will bring that up later)

John Moehrke (Dec 06 2021 at 21:30):

all of my errors (42) are around slicing of my extension

John Moehrke (Dec 06 2021 at 22:03):

I might have stumbled on an issue... In my case I had a base profile that setup the initial conditions for the .agent[user] slice. I derived a second profile off of that and further elaborated what you see. When I explicitly copy that first profile in to the second; The problems are less noisy, but not sure they are better

AuditEvent.agent[0].extension[0] (l32/c10)  error   Slicing cannot be evaluated: illegal expression syntax in discriminator (group) (@char 3)
AuditEvent.agent[0].extension[1] (l43/c10)  error   Slicing cannot be evaluated: illegal expression syntax in discriminator (group) (@char 3)
AuditEvent.agent[0].extension[2] (l59/c10)  error   Slicing cannot be evaluated: illegal expression syntax in discriminator (group) (@char 3)
AuditEvent.agent[0].extension[3] (l75/c10)  error   Slicing cannot be evaluated: illegal expression syntax in discriminator (group) (@char 3)

Chris Moesel (Dec 06 2021 at 22:12):

Those errors seem very different. I don't know what's going on there.

Chris Moesel (Dec 06 2021 at 22:19):

I cloned your repo and built it -- then manually edited the JSON StructureDefinition profile so that the slices declared the correct type (for the ihe-otherId extension). When I did that, the errors changed to errors like this:

AuditEvent.agent[0].extension[1] (l43/c10) error Profile http://profiles.ihe.net/ITI/BasicAudit/StructureDefinition/ITI.BasicAudit.SAMLaccessTokenUse.Comprehensive.Norway, Element matches more than one slice - otherId, otherId/subject-id

I don't understand this error because otherId/subject-id is a reslice of otherId -- so of course the element matches against both. It can't match on otherId/subect-id without also matching on otherId. @Lloyd McKenzie, am I missing something? Wouldn't you expect an element that matches a reslice to also match the top-level slice? Shouldn't the validator know to prefer the more specific re-slice?

Lloyd McKenzie (Dec 06 2021 at 23:38):

Yeah, that seems a little odd as a message. @Grahame Grieve?

John Moehrke (Dec 07 2021 at 14:29):

@Grahame Grieve here is my github repo with this IG https://github.com/IHE/ITI.BasicAudit

John Moehrke (Dec 07 2021 at 15:13):

I created a mini IG that has the minimum needed to show the problem I have https://github.com/JohnMoehrke/SlicingSlicedExtension

John Moehrke (Dec 07 2021 at 15:14):

Extension: OtherId
Title: "AuditEvent.agent other identifiers"
Description: "Carries other identifiers that are known for an agent."
* value[x] only Reference


Profile:        SecondSliceProfile
Parent:         AuditEvent
Title:          "Profile with slices of extension in a slice"
Description:    """
- slices .agent[user]
- slices .agent extension otherId
"""
* agent.extension contains OtherId named otherId 0..* MS
* agent ^slicing.discriminator.type = #pattern
* agent ^slicing.discriminator.path = "type"
* agent ^slicing.rules = #open
* agent contains
    user 1..
* agent[user].type = http://terminology.hl7.org/CodeSystem/v3-ParticipationType#IRCP "information recipient"
* agent[user].who 1..1
* agent[user].extension[otherId] ^slicing.discriminator.type = #pattern
* agent[user].extension[otherId] ^slicing.discriminator.path = "(value as Reference).identifier.type"
* agent[user].extension[otherId] ^slicing.rules = #open
* agent[user].extension[otherId] contains
    npi 0..1 and
    provider-id 0..1
* agent[user].extension[otherId][npi].valueReference.identifier.type = http://terminology.hl7.org/CodeSystem/v2-0203#NPI
* agent[user].extension[otherId][provider-id].valueReference.identifier.type = http://terminology.hl7.org/CodeSystem/v2-0203#PRN

Grahame Grieve (Dec 08 2021 at 05:34):

the problem is here:

Slice: Unordered, Open by pattern:(value as Reference).identifier.type

because the rule is https://hl7.org/fhir/fhirpath.html#simple:

• All statements SHALL start with the name of the context element (e.g. on a Patient resource, Patient.contact.name.), or SHALL be simply "$this" to refer to the element that has focus
• Operators SHALL NOT be used
• Only the following functions may be used:
  • .resolve()
  • .extension("url")
  • .ofType(type)

Grahame Grieve (Dec 08 2021 at 05:34):

so the descriminator needs to be

Grahame Grieve (Dec 08 2021 at 05:35):

$this.value.ofType(Reference).identifier.type

John Moehrke (Dec 08 2021 at 12:00):

I knew it was my fault. Thankyou @Grahame Grieve
Note, I now get an error illegal use of ofType()

Grahame Grieve (Dec 08 2021 at 17:54):

did you commit that?

John Moehrke (Dec 08 2021 at 18:19):

yes

John Moehrke (Dec 09 2021 at 13:52):

any other recommendations for solving this? My sample IG has the last recommendation, and qa shows the new failure.
https://github.com/JohnMoehrke/SlicingSlicedExtension/

Grahame Grieve (Dec 09 2021 at 19:18):

it's on my todo list

Grahame Grieve (Dec 22 2021 at 11:27):

so I had a go at this but I think there's something wrong with your definitions. Have a look at the test case I've just added to the validator tests - which seems to work, and compare it with yours. I don't think you've got the slicing set up quite right

John Moehrke (Dec 22 2021 at 14:26):

The difference I detect is that you don't use the '/' character in the sliceName and the id of that slice. I see that id datatype doesn't allow '/' character. (I did see it in other id elements in that example. Seems like a sushi problem?

Chris Moesel (Dec 22 2021 at 14:43):

I have not had the time to look at Grahame's example, but the / character is used when you are re-slicing. In other words, if there is an existing slice defined and you need to create sub-slices within that slice, this is called re-slicing. And in re-slicing, the sliceName is ${parentSliceName}/{subSliceName}. See Re-profiling and Re-slicing (particularly the last paragraph).

John Moehrke (Dec 22 2021 at 14:53):

sorry for the distraction, I tried fixing the '/'.. not the problem.

John Moehrke (Dec 23 2021 at 13:13):

latest build still fails on this. Deeper discussion of the problem https://chat.fhir.org/#narrow/stream/215610-shorthand/topic/slicing.20with.20complex.20.24this
The problem is identified, the solution is not so clear. Is this sushi or validator issue to resolve?

Grahame Grieve (Dec 23 2021 at 13:20):

well, it passes my test. did you compare the two?

John Moehrke (Dec 23 2021 at 13:23):

yes, that is what is in the other stream

John Moehrke (Dec 23 2021 at 13:24):

I didn't want to duplicate, and the issue is related to sushi handling

Chris Moesel (Dec 23 2021 at 19:16):

I'm not so sure it is related to SUSHI handling. John's solution was to remove the sliceName property from the element with id: AuditEvent.agent:user.extension:otherId. Since that element clearly is a slice, then I think it's completely appropriate for SUSHI to include the sliceName in the differential. In fact, based on previous conversations, I was under the impression that we must always put sliceName in the differential for a slice element.

@Grahame Grieve -- I also found some things in your test example that didn't seem right to me based on my understanding of slicing, re-slicing, and the relationship between sliceName and id.

Chris Moesel (Dec 23 2021 at 19:17):

Details are in the other thread.

John Moehrke (Dec 31 2021 at 13:59):

@Grahame Grieve poke

John Moehrke (Mar 15 2022 at 16:14):

I have created a test IG that focuses only on the situation I have. I am slicing an extension that is within a slice.. and am struggling. -- http://build.fhir.org/ig/JohnMoehrke/SlicingSlicedExtension/branches/main/index.html

John Moehrke (Mar 15 2022 at 16:14):

I keep getting errors, so I presume I am defining my slicing discriminator

* agent[user].extension[extOtherId] ^slicing.discriminator.type = #value
* agent[user].extension[extOtherId] ^slicing.discriminator.path = "$this.value.ofType(Reference).identifier.type"
* agent[user].extension[extOtherId] ^slicing.rules = #open
* agent[user].extension[extOtherId] contains

John Moehrke (Mar 15 2022 at 16:15):

tried #value and #pattern.. same result

John Moehrke (Mar 15 2022 at 16:15):

so on my examples in that IG I get validation error

Slicing cannot be evaluated: Could not match discriminator ([$this.value.ofType(Reference).identifier.type]) for slice AuditEvent.agent:user.extension:extOtherId in profile http://johnmoehrke.github.io/SlicingSlicedExtension/StructureDefinition/ThirdSliceProfile - the discriminator [$this.value.ofType(Reference).identifier.type] does not have fixed value, binding or existence assertions

Chris Moesel (Mar 16 2022 at 21:05):

OK. I have been looking into this and experimenting w/ it. I think it comes down to quirks (bugs?) in snapshot generation.

Here is the basic slicing structure of John's example profile:

• AuditEvent.agent is sliced by pattern on type
  • Slices: user, userorg
• AuditEvent.agent.extension is sliced by value on url (typical extension slicing)
  • Slices: extOtherId
• AuditEvent.agent:user.extension:extOtherId is resliced by pattern on $this.value.ofType(Reference).identifier.type
  • Slices: extOtherId/npi, extOtherId/provider-id

The first problem I noticed is that the snapshot generator was putting the re-slicing information on the wrong element. John's example had this in the differential:

{
  "id": "AuditEvent.agent:user",
  "path": "AuditEvent.agent",
  "sliceName": "user",
  "min": 1,
  "max": "*"
},
{
  "id": "AuditEvent.agent:user.extension:extOtherId",
  "path": "AuditEvent.agent.extension",
  "sliceName": "extOtherId",
  "slicing": {
    "discriminator": [{ "type": "pattern", "path": "$this.value.ofType(Reference).identifier.type" }],
    "rules": "open"
  },
  "min": 0,
  "max": "*",
  "type": [
    {
      "code": "Extension",
      "profile": ["http://johnmoehrke.github.io/SlicingSlicedExtension/StructureDefinition/OtherId"]
    }
  ],
  "mustSupport": true
}

Note that the re-slicing info is on AuditEvent.agent:user.extension:extOtherId.

But the snapshot was coming out like this (I've omitted properties for brevity):

{
  "id": "AuditEvent.agent:user",
  "path": "AuditEvent.agent",
  "sliceName": "user",
  "...": ""
},
{
  "id": "AuditEvent.agent:user.id",
  "path": "AuditEvent.agent.id",
  "...": ""
},
{
  "id": "AuditEvent.agent:user.extension",
  "path": "AuditEvent.agent.extension",
  "slicing": {
    "discriminator": [{ "type": "pattern", "path": "$this.value.ofType(Reference).identifier.type" }],
    "rules": "open"
  },
  "...": ""
},
{
  "id": "AuditEvent.agent:user.extension:extOtherId",
  "path": "AuditEvent.agent.extension",
  "sliceName": "extOtherId",
  "...": "",
  "type": [
    {
      "code": "Extension",
      "profile": [
        "http://johnmoehrke.github.io/SlicingSlicedExtension/StructureDefinition/OtherId"
      ]
    }
  ],
  "...": ""
}

Note that the re-slicing information (by pattern on the identifier type) is now on the wrong element. It's on AuditEvent.agent:user.extension instead of AuditEvent.agent:user.extension:extOtherId.

I wondered if maybe the snapshot generator needed the AuditEvent.agent:user.extension to redeclare its slicing in the differential (even though the slicing was already declared in the sliced element). So I added that element to the differential as below:

{
  "id": "AuditEvent.agent:user",
  "path": "AuditEvent.agent",
  "sliceName": "user",
  "min": 1,
  "max": "*"
},
{
  "id": "AuditEvent.agent:user.extension",
  "path": "AuditEvent.agent.extension",
  "slicing": {
    "discriminator": [{ "type": "value", "path": "url" }],
    "ordered": false,
    "rules": "open"
  }
},
{
  "id": "AuditEvent.agent:user.extension:extOtherId",
  "path": "AuditEvent.agent.extension",
  "sliceName": "extOtherId",
  "slicing": {
    "discriminator": [{ "type": "pattern", "path": "$this.value.ofType(Reference).identifier.type" }],
    "rules": "open"
  },
  "min": 0,
  "max": "*",
  "type": [
    {
      "code": "Extension",
      "profile": ["http://johnmoehrke.github.io/SlicingSlicedExtension/StructureDefinition/OtherId"]
    }
  ],
  "mustSupport": true
}

(The 2nd element above is what I added to the differential in John's example).

But now the snapshot generator had the correct slicing on AuditEvent.agent:user.extension, but completely omitted the reslicing on AuditEvent.agent:user.extension:extOtherId:

{
  "id": "AuditEvent.agent:user",
  "path": "AuditEvent.agent",
  "sliceName": "user",
  "...": ""
},
{
  "id": "AuditEvent.agent:user.id",
  "path": "AuditEvent.agent.id",
  "...": ""
},
{
  "id": "AuditEvent.agent:user.extension",
  "path": "AuditEvent.agent.extension",
  "slicing": {
    "discriminator": [{ "type": "value", "path": "url" }],
    "ordered": false,
    "rules": "open"
  },
  "...": ""
},
{
  "id": "AuditEvent.agent:user.extension:extOtherId",
  "path": "AuditEvent.agent.extension",
  "sliceName": "extOtherId",
  "_NOTE: We should see a slicing here with the re-slicing information": "",
  "...": "",
  "type": [
    {
      "code": "Extension",
      "profile": [
        "http://johnmoehrke.github.io/SlicingSlicedExtension/StructureDefinition/OtherId"
      ]
    }
  ],
  "...": ""
}

Note that the slicing is gone from AuditEvent.agent:user.extension:extOtherId. Without that reslicing info, the extOtherId/npi and extOtherId/provider-id slices aren't valid slices (since they're no longer unique according to the discriminator). So that just caused different errors in validation.

I'd prefer that we do not need to redeclare slicings that have already been defined on a sliced element (approach 1 above), but I know the IG Publisher is limited in its ability to see and carry over constraints from the sliced element.

But I'm pretty sure approach 2 above should work. I'm not sure why the snapshot generator is dropping the reslicing information on AuditEvent.agent:user.extension:extOtherId. @Grahame Grieve?

John Moehrke (Mar 21 2022 at 16:26):

@Lloyd McKenzie @Grahame Grieve can you help with how this should look?

John Moehrke (Mar 21 2022 at 19:31):

given some discussion today in security, that leads my use-case to be simplified to just adding extensions that are Identifiers, rather that References that I only use as Identifiers. So I simplified my test IG, and even the more simple version fails. Note that this doesn't even slice the extension within a slice, I defined the fine grain slice in a way independent of the gross slice... so I am very conflused as to why this one is not working.

John Moehrke (Mar 21 2022 at 19:41):

in this version I am defining the otherId slice independent of the user slice, and using the more simple Identifier. Thus my discriminator is much easier too. but still no love at the example validation.

John Moehrke (Mar 28 2022 at 13:05):

I am still stuck. Might this be similar to the nested sections slicing problem? Seems similar.

João Almeida (Mar 28 2022 at 13:08):

John Moehrke said:

I am still stuck. Might this be similar to the nested sections slicing problem? Seems similar.

sushi works with your example or only the IG Publisher?
The nested section only fails on the IGPub

John Moehrke (Mar 28 2022 at 13:08):

yes, for me it really only fails on validating my examples.

John Moehrke (Mar 28 2022 at 13:09):

see above for the long discussion.

John Moehrke (Mar 28 2022 at 13:09):

it seems that the validator is expecting something in the profile that I am not smart enough to put in there.

João Almeida (Mar 28 2022 at 13:13):

yes indeed, the "symptoms" seem similar to the nested section

Grahame Grieve (Mar 30 2022 at 00:24):

well, I think that the snapshot is correct, and what is trying to be done is the problem

Grahame Grieve (Mar 30 2022 at 00:29):

the problem is that the all slices definition of agent defines a slice OtherId, and then so does the user slice on it. So that overrides the slice

Chris Moesel (Mar 30 2022 at 13:46):

@Grahame Grieve -- my understanding was that the validator cannot (or does not) look back to the all slices definition during validation. In the past, we've had to repeat constraints (such as extension declarations) in each slice for this very reason. So without the OtherId slice definition on the agent slice (which I view as redundant, rather than an override), the validator wouldn't know the OtherId slice exists. Is my understanding incorrect? Does the validator consider the all-slice constraints now when processing each individual slice?

John Moehrke (Mar 30 2022 at 14:08):

Grahame Grieve said:

the problem is that the all slices definition of agent defines a slice OtherId, and then so does the user slice on it. So that overrides the slice

I would far prefer this, but it gives the same problem.

Grahame Grieve (Mar 31 2022 at 02:53):

well, I think that @Chris Moesel is right, but the slice doesn't pick up anything from the all slices slice, and so the validator doesn't know how to resolve the slices

John Moehrke (Mar 31 2022 at 12:43):

so, what should the json look like?

Chris Moesel (Mar 31 2022 at 13:20):

@Grahame Grieve - John and I have experimented w/ many different formations of the SD and haven't been able to find a successful representation that passes instance validation without error. If you can provide a differential that works, I suspect we can learn from it and then apply it to future situations. But like John, I am stumped -- and I don't know if everything we've tried is truly wrong or if we're just hitting validator or publisher bugs/limitations.

Grahame Grieve (Apr 05 2022 at 03:23):

@Chris Moesel @John Moehrke I have spent a few days looking at this. I do not believe that what you are doing with the slices makes sense or is documented.

Grahame Grieve (Apr 05 2022 at 03:23):

the relevant documentation is

Grahame Grieve (Apr 05 2022 at 03:23):

In addition to the above, there are times when Profile C will need to further slice a slice defined in B. In this case, there's a need to reference both the ElementDefinition.sliceName of the original slice from Profile B as well as to define an ElementDefinition.sliceName for the slice defined within Profile C. This is done by separating the names using "/". For example, if Profile B defines the slice "example", and profile C defines the slice "example/example1", then this is deemed to be "example1" slice of the example slice. This process can continue indefinitely by separating each layer of slicing names with the "/" character. This pattern applies to @default too: @default/@default.

Grahame Grieve (Apr 05 2022 at 03:24):

The documentation talks about doing this from one profile to another. There's nowhere that says you can just go right ahead and do this in the same profile

Grahame Grieve (Apr 05 2022 at 03:24):

which is what's happening here.

Grahame Grieve (Apr 05 2022 at 03:24):

but I went ahead and implemented the snapshot generation to do that anyway. But then validation gives you:

Grahame Grieve (Apr 05 2022 at 03:25):

RROR: AuditEvent.agent[0].extension[0]: Profile http://hl7.org/fhir/test/StructureDefinition/Slice23, Element matches more than one slice - extOtherId, extOtherId/npi

Grahame Grieve (Apr 05 2022 at 03:25):

and indeed it does, and must.

Grahame Grieve (Apr 05 2022 at 03:26):

I don't see how what you're doing can work

Grahame Grieve (Apr 05 2022 at 03:29):

so what are you actually trying to achieve?

John Moehrke (Apr 05 2022 at 12:08):

Here is what I am trying to do, I would be happy for someone to express how to do this in json/xml.

1. I need to slice the AuditEvent.agent as there are multiple kinds of agent the profile is defining, so want to identify a slice for the (user) agent.
2. In that slice for describing the user, I have more identifiers to record than the AuditEvent.agent supports. so I add an extension (extOtherIds)
3. In that extension that allows me to record more identifiers, I have a some flavors of identifier that I also want to define (npi, and prn)

Note: For 2, I have tried to define this in the first (user) slice, and have tried it at the root.

Here is my github - https://github.com/JohnMoehrke/SlicingSlicedExtension

John Moehrke (Apr 05 2022 at 12:11):

This github is very focused only on this problem/need.

Last updated: Apr 12 2022 at 19:14 UTC