FHIR Chat · New validation error "Unsupported fixed pattern type..." · IG creation

Stream: IG creation

Topic: New validation error "Unsupported fixed pattern type..."

Jean Duteau (Mar 27 2020 at 20:47):

With the latest publisher, I am now getting the following error that I wasn't before:
Unsupported fixed pattern type for discriminator(system) for slice xxx

I have three slices on Organization.telecom on telecom.system. Phone requires system to be #phone, Fax requires system to be #fax, and Email requires system to be #email.

I have this in my example:
"telecom" : [ { "system" : "email", "value" : "faersedub@fda.hhs.gov" } ],

And I get the following errors:
Unsupported fixed pattern type for discriminator(system) for slice Organization.telecom:Phone: org.hl7.fhir.r5.model.CodeType
Unsupported fixed pattern type for discriminator(system) for slice Organization.telecom:Fax: org.hl7.fhir.r5.model.CodeType
Unsupported fixed pattern type for discriminator(system) for slice Organization.telecom:Email: org.hl7.fhir.r5.model.CodeType

I can't really tell from the error message what is wrong, but it seems to be saying that my slice definitions in the profile are wrong? But it looks correct to me.

Lloyd McKenzie (Mar 27 2020 at 20:58):

Unsupported means that the publisher doesn't currently support handling patterns for ContactPoint. (The number of types supported is actually pretty small so far - Coding, CodeableConcept, and maybe one or two others.). We'll have to change the IGPublisher to support this type. I'll see if I can do it.

Grahame Grieve (Mar 27 2020 at 20:58):

right. and this is nothing to do with the new publisher.

Jean Duteau (Mar 27 2020 at 20:59):

hmm, I'm not asking for a pattern slice. It is specified as a value slice.
this wasn't broken before, so it might be that the new sushi created the profile differently. i'll go look.

Jean Duteau (Mar 27 2020 at 21:00):

Yeah, this isn't a pattern slice...

    "id": "Organization.telecom",
    "path": "Organization.telecom",
    "slicing": {
      "discriminator": [
        {
          "type": "value",
          "path": "system"
        }
      ],
      "rules": "open",
      "description": "Slice based on the different telecom types (systems)"
    }
  },

Grahame Grieve (Mar 27 2020 at 21:00):

what version is this IG?

Jean Duteau (Mar 27 2020 at 21:02):

hmm, but the actual slice definitions use 'patternCode' instead of 'fixedCode' like I'd expect:
{
"id": "Organization.telecom:Phone.system",
"path": "Organization.telecom.system",
"patternCode": "phone"
},

Grahame Grieve (Mar 27 2020 at 21:03):

well, that's why you're getting that message

Jean Duteau (Mar 27 2020 at 21:03):

too many moving parts :(

Chris Moesel (Mar 27 2020 at 21:42):

Unsupported means that the publisher doesn't currently support handling patterns for ContactPoint. (The number of types supported is actually pretty small so far - Coding, CodeableConcept, and maybe one or two others.)

So that's a bit of a surprise. I thought @Lloyd McKenzie was an advocate for using patterns even on primitives, so as to allow ids and extensions on them. Am I misunderstanding something here?

Rick Geimer (Mar 27 2020 at 21:45):

Agreed, I would expect pattern to be well supported by now. I've been discouraging our analysts from using fixed wherever possible.

Jean Duteau (Mar 27 2020 at 21:48):

I looked in the code and pattern only works for CodeableConcept, Coding, and Identifier. It errors out for any other type.

Lloyd McKenzie (Mar 27 2020 at 22:32):

I don't think there's a misunderstanding. At present, the code for pattern is type-specific and is being added 'as needed'. I'd been holding off on doing anything as I wasn't clear on whether Jean's issue was a publisher issue or a FSH issue. Jean, do you need the publisher changed? If so, seeing as you've already found the code, do you want to make the pull request yourself?

Jean Duteau (Mar 27 2020 at 23:10):

I have a workaround in FSH to make it specify the match as fixed. My specific issue was a code pattern (as opposed to a ContactPoint pattern) and that should be easy to fix, but that sort of seems like a bandaid.

Jean Duteau (Mar 27 2020 at 23:12):

I may make a pull request just to fix the method name - buildPattternExpression has one two many 't's. :)

Chris Moesel (Mar 28 2020 at 01:56):

We just introduced a feature in FSH and SUSHI that makes pattern much more prevalent, under the understanding that pattern was generally preferred since it usually accomplished what the author wanted while not being overly constraining. When we proposed this earlier, no one mentioned this limitation of the publisher. Do we need to revisit this in FSH? Should we warn users when they use patterns on apparently unsupported types? Or can the publisher easily add more robust support for patterns?

Grahame Grieve (Mar 28 2020 at 02:24):

publisher can easily add it. We just haven't got around to it yet.

Grahame Grieve (Mar 28 2020 at 02:24):

it's called JIT programming ;-)

Chris Moesel (Mar 29 2020 at 22:23):

@Grahame Grieve - if it doesn’t require in depth knowledge of the publisher, maybe someone on my team can do it. Is it pretty straight forward?

Grahame Grieve (Mar 29 2020 at 22:28):

not particularly straight forward

Chris Moesel (Mar 29 2020 at 22:30):

Darn.

Grahame Grieve (Mar 29 2020 at 22:32):

I can do it. We just haven't had anyone using pattern on much other than CodeableConcept, Identifier and ContactPoint. It's been on the list to do when we don't have anything else to do or when someone tries to use one of them

Last updated: Apr 12 2022 at 19:14 UTC