Stream: IG creation
Topic: Types must be unique (code vs Coding)
Chris Moesel (Aug 08 2018 at 20:32):
The IG Publisher is reporting the following error for one of our logical model structure definitions:
Types must be unique by the combination of code and profile [type.select(code&profile&targetProfile).isDistinct()]
When I look at the element it refers to, however, the codes are unique:
"type" : [
{
"code" : "code"
},
{
"code" : "Coding"
}
],
Now you can argue that maybe allowing a choice between a code and a Coding isn't a great idea, but... I don't understand why this invariant is getting triggered since they are technically unique. Is there special logic in the invariant processing that treats code and Coding the same?
Grahame Grieve (Aug 08 2018 at 20:33):
no special logic. It doesn't look right to me either
Chris Moesel (Aug 08 2018 at 20:36):
OK. Thanks for the confirmation. There must be something else going on. I'll dig in a little more. Although this whole model only has two elements (it's kind of a silly one) -- so there's not much I could have missed!
Lloyd McKenzie (Aug 08 2018 at 21:37):
We may have an internal rule that prohibits that combination as it's a nonsensical thing to do, but the error message could be better.
Lloyd McKenzie (Aug 08 2018 at 21:37):
If you're going to support Coding, there's never a reason to allow 'code'.
Grahame Grieve (Aug 08 2018 at 23:17):
can I reproduce this easily?
Chris Moesel (Aug 09 2018 at 00:02):
I hear you @Lloyd McKenzie. I agree it's probably a silly thing to do. I haven't yet asked why we're doing it. The error message just surprised me.
@Grahame Grieve -- I expect you can repro it by simply creating a logical model with an element that has a choice between code and Coding. But if you want to reproduce it with existing code, you can build US BreastCancer and look at the cimi-element-Status-model. BUT... perhaps I should find out if it's really necessary for us to create a choice between a code and a Coding before you chase this down too far?
Grahame Grieve (Aug 09 2018 at 00:16):
well, I'm looking at stuff like this today anyway, and I while agree that the choice reflects a bad understanding of terminology (or what can go wrong) it still looks like an infrastructural problem to me
Chris Moesel (Aug 09 2018 at 00:26):
OK. In looking at it further, I suspect the model was done this way to allow it to be easily mapped onto resource properties that might be code or Coding (or CodeableConcept, but we supress that for a different reason). So it's probably more of a side-effect of a tooling approach than an intentional decision about the model. That said, I think we can find another way.
Grahame Grieve (Aug 09 2018 at 00:27):
there might be some sense in that somewhere
Grahame Grieve (Aug 09 2018 at 03:01):
@Chris Moesel this is what I see:
"type": [
{
"code": "code"
},
{
"code": "Coding"
},
{
"code": "Coding"
}
],
That will fail the test, no doubt
Chris Moesel (Aug 09 2018 at 03:09):
Oh no. If that's what's really there then I feel like a moron. I am sorry.
Chris Moesel (Aug 09 2018 at 03:13):
Ugh. You're right. I was looking at the JSON linked from the IG (http://build.fhir.org/ig/HL7/us-breastcancer/StructureDefinition-cimi-element-Status-model.json). I didn't realize that was a _sanitized_ version of what the source actually was (https://github.com/HL7/us-breastcancer/blob/master/resources/structuredefinition-cimi-element-Status-model.json). I learned something today and I hope I did not waste much of your time, @Grahame Grieve!
Grahame Grieve (Aug 09 2018 at 03:14):
found it straight away, so no time lost
Last updated: Apr 12 2022 at 19:14 UTC
