Stream: implementers
Topic: datatypes and [x]
Josh Mandel (Mar 18 2016 at 14:00):
I'm looking at Goal.target[x]and one of the options is targetQuantity. This should really be targetDuration. Is it a tooling error that causes this?
Michel Rutten (Mar 18 2016 at 14:03):
From Goal DSTU2 StructureDefinition, element definition for Goal.target[x]:
<type>
<code value="Quantity"/>
<profile value="http://hl7.org/fhir/StructureDefinition/Duration"/>
</type>
This week I discussed choice element renaming with Ewout. According to the spec, the [x] should be replaced by a base type, in this case Quantity.
Josh Mandel (Mar 18 2016 at 14:30):
Ah, so this was intentional. In that case, let me just say I think we should reevaluate the decision. Because it makes tthe data models very difficult to understand.
Michel Rutten (Mar 18 2016 at 14:39):
According to this approach, Duration, Money etc. are considered to be (official) profiles on Quantity, which is the actual core type. Recently, I've been working on support for derived core types in Forge. Currently I consider Quantity to be the actual type name, and Money/Duration/... as a profile name. This is similar to derived profiles created by users, except that the canonical url starts with the standard prefix http://hl7.org/fhir/StructureDefinition. I'm still working on some nitty gritty details, but the approach seems to work.
Michel Rutten (Mar 18 2016 at 14:48):
In the currently suggested approach, all derived profiles are treated equally, regardless of wether they are official (Money) or user-defined (e.g. Dollar profile): replace the [x] with the actual base type (e.g. Quantity). As far as I can determine right now, this does seem to simplify some of the type resolving logic, as opposed to defining special rules for official derived profiles.
Ewout Kramer (Mar 18 2016 at 14:53):
Ha! This issue again. Yes, it seems, except for Grahame, no one has realized this. So the subtypes of Quantity aren't really subtypes, they are just profiles. So, we had to change the serializer to turn valueAge into valueQuantity. So, yes, it is intentional. However, the current datatype page and valuets like http://hl7.org/fhir/valueset-defined-types.html still list those as "types". This is all very confusing. gForge #8916 and #9168 have been raised as a reaction to this.
Grahame Grieve (Mar 18 2016 at 18:19):
Duration is not a type, it's a profile on a type. So it cannot be in the serialization as a type. I'm not sure why this is causing such confusion
Josh Mandel (Mar 18 2016 at 18:20):
It's causing such confusion because the field in the Goal resource is called targetQuantity, and this makes no sense. I can't read that field name and understand it.
Josh Mandel (Mar 18 2016 at 18:22):
I'm not talking about data type definitions.
Josh Mandel (Mar 18 2016 at 18:22):
I'm talking about reading the field name Goal.targetQuantity and (not!) understanding what it means.
Grahame Grieve (Mar 18 2016 at 18:23):
Yes that happened with other fields as well
Josh Mandel (Mar 18 2016 at 18:23):
I'm sure it did. This is just the first one I happened to notice.
Grahame Grieve (Mar 18 2016 at 18:24):
I didn't like that outcome either. But you can't invent special cases to workaround that kind of stuff and still have something that actually works
Eric Haas (Mar 19 2016 at 00:27):
so is this really a publishing issue - ie what we read in the the JSON rendition is clear :
Eric Haas (Mar 19 2016 at 00:27):
"targetQuantity" : { Quantity(Duration) }
Eric Haas (Mar 19 2016 at 00:31):
in the structure is less clear when I read it since I look at type and see "Duration" and think "Duration" so when targetQuantity popup I like Josh think its an error.
Eric Haas (Mar 19 2016 at 00:31):
maybe type should read Quantity(Duration)
Eric Haas (Mar 19 2016 at 00:32):
Though thats not much better. Can't we just hide it :-)
Grahame Grieve (Mar 19 2016 at 07:20):
in the structure, we always replace the type with the profile name
Grahame Grieve (Mar 19 2016 at 07:20):
irrespective of where we are
Eric Haas (Mar 19 2016 at 17:48):
Its just that the words don't match one's expectation so reader is left puzzled like when you are drving down Main street and then next block the street name changes to Elm. I don't how or if we can fix it but its an issue.
Grahame Grieve (Mar 19 2016 at 20:04):
I don't understand. The structure is quite specific: it shows both the element name, and the profile or type name. where is the uncertainty?
Josh Mandel (Mar 19 2016 at 21:04):
The field "targetQuantity" just doesn't make sense.
Josh Mandel (Mar 19 2016 at 21:05):
It sounds like you're giving a patient a quantity as a goal (e.g. "lose 25 pounds"). But in fact it's describing a duration of time.
Lloyd McKenzie (Mar 19 2016 at 21:21):
What is the alternative work-around? I don't think we want profile names manifesting in the wire format...
Grahame Grieve (Mar 19 2016 at 21:32):
Well, we could treat those profiles special as concrete types. That would be possible, but would make them special.
Lloyd McKenzie (Mar 19 2016 at 23:18):
Money and Duration might make sense as distinct. Don't agree with "Length" (and not sure we even use it in the core spec). There will be all sorts of profiles that are equivalent to that one.
Grahame Grieve (Mar 20 2016 at 00:01):
I don't really favour making them special. There's lot of places where you would use vanilla quantity for money or duration
Michael van der Zel (Mar 20 2016 at 10:06):
Does UCUM help us here?
Grahame Grieve (Mar 20 2016 at 10:10):
how would it help?
Michael van der Zel (Mar 20 2016 at 10:11):
It sounds to me we are looking for a clear separation of datatype vs specific unit families.
Michael van der Zel (Mar 20 2016 at 10:15):
E.g. by "kind of quantity".
Patrick Werner (Mar 20 2016 at 10:18):
i agree with josh, if you aren't familiar with the Goal Resource targetQuantity sounds like the value the patient should accomplish. In the preparation phase for the last dev-days the students got confused by that a lot.
The start of a goal is named "start" if target would be named "end" or something similar it could be less confusing for beginners
Michael van der Zel (Mar 20 2016 at 10:31):
Ah. Now I see. I see. I was confused also. I thought that target was the target of the goal. So I was thinking of a weight. Then I agree with Patrick that renaming it to "end" makes sense.
Josh Mandel (Mar 20 2016 at 15:01):
And you think endQuantity would convey "this is the amount of time it should take you to accomplish your goal" @Michael van der Zel and @Patrick Werner ?
Paul Knapp (Mar 20 2016 at 17:25):
When would you use Qualtity in place of Money when you mean money - when you don't know the currency?
Paul Knapp (Mar 20 2016 at 17:26):
I think it would be clearer if we used the profile name rather than the base type as the name.
Michael van der Zel (Mar 20 2016 at 19:17):
@Josh Mandel No I would say endDuration.
Grahame Grieve (Mar 20 2016 at 21:48):
of course we'd like it to say endDuration. But we wouldn't want the wire format to change for any other use of profiles, so that would make the special. And special cases are troublesome. But we did say that the primitives that are defined as derivations are actually data types , not profiles on the data types, so we could say that for these too - that would be the way which we would say they were special
Grahame Grieve (Mar 20 2016 at 21:49):
I do believe that this issue has missed the boat for Montreal connectathon though
Grahame Grieve (Mar 20 2016 at 21:51):
btw, I believe this issue has an FMM level of 2, since the highest FMM for a resource that is affected by this issue is 2 (Condition)
Lloyd McKenzie (Mar 21 2016 at 02:32):
It affects all uses of extensions too, I believe.
Grahame Grieve (Mar 21 2016 at 02:55):
yes, but that doesn't change my opinion on the FMM level
Lloyd McKenzie (Mar 21 2016 at 03:08):
Are extensions FMM2?
Grahame Grieve (Mar 21 2016 at 03:09):
we haven't said, as far as I'm aware
James Agnew (Mar 25 2016 at 21:52):
This issue has caused me so much confusion in the last year.. I've gotten the implementation wrong, then corrected it, then realized the correction was only half right.
If anyone cares, the status quo right now (at least if I understand it) is that profiled types like "Money" don't get serialized as valueMoney, but profiled primitive types such as markdown get serialized as valueMarkdown because they aren't really profiled types.
It is certainly confusing. I think we should just plain say that any profiles defined in the core spec are distinct types and get serialized as such.
Grahame Grieve (Mar 25 2016 at 22:00):
That had been my original intention, but Lloyd, in particular, was fiercely opposed to that
James Agnew (Mar 25 2016 at 22:08):
@Lloyd McKenzie what's your opposition? The fact that this continues to confuse even the so called experts tells me we have a problem :)
Lloyd McKenzie (Mar 25 2016 at 23:23):
I'm comfortable with things like Money and perhaps Duration. But "Length" is a sibling of what could be 50+ equivalent profiles (Volume, Mass, Area, Density . . .) As well, it means that our profiles behave differently than everyone else's profiles, which creates change whenever we introduce a new profile and also creates pressure for people to want their profiles migrated into the international spec
Grahame Grieve (Mar 26 2016 at 00:34):
Lloyd thought that we should be consistent and not call them special. Also, it would be only place where we have explicit specialisation of a concrete type. (Though that wasnt Lloyds concern)
Grahame Grieve (Mar 26 2016 at 01:30):
Well, they've been pretty stable, that list. I don't think change should be such a concern to us
Lloyd McKenzie (Mar 26 2016 at 03:10):
Does anything use "Length"?
Grahame Grieve (Mar 26 2016 at 05:01):
Doesn't look like it
Grahame Grieve (Mar 26 2016 at 05:01):
one of the problems of treating those as types is that you can't use them as profiles on quantity in a profile - if you wanted to
Lloyd McKenzie (Mar 26 2016 at 14:19):
Yes. And having both a type and a profile way of expressing them is clunky too.
Last updated: Apr 12 2022 at 19:14 UTC
