Stream: conformance
Topic: How to constrain datatype
Vadim Peretokin (Jul 08 2019 at 10:55):
How does one constrain a datatype? https://www.hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.type.profile says it can match any of the profiles, which invalidates it for the purposes of constraining because the datatype will always match the base profile in the specification.
Jose Costa Teixeira (Jul 08 2019 at 14:23):
I have a (possibly) related question: Can we say somewhere that for a given element, the max string length is 1K characters, instead of 1M?
Jose Costa Teixeira (Jul 08 2019 at 14:25):
is that the goal of ElementDefinition.maxLength ?
Eric Haas (Jul 08 2019 at 15:03):
@Jose Costa Teixeira yes
Grahame Grieve (Jul 08 2019 at 19:53):
I don't understand this question
Vadim Peretokin (Jul 09 2019 at 07:46):
I want to constrain SimpleQuantity to ensure that code is always present for a particular profile of mine
Vadim Peretokin (Jul 09 2019 at 07:46):
ElementDefinition.type.profile looks like should do the job is that correct?
Richard Townley-O'Neill (Jul 10 2019 at 00:16):
@Vadim Peretokin
Do you want to use an invariant or create a profile of SimpleQuantity?
Hl7 AU has a profile of the data type Address. See http://hl7.org.au/fhir/base/aubase1/StructureDefinition-au-address.html
Vadim Peretokin (Jul 10 2019 at 04:41):
@Richard Townley-O'Neill Do you use that extension anywhere?
Vadim Peretokin (Jul 10 2019 at 04:41):
The problem I have is with applying it so validation works
Richard Townley-O'Neill (Jul 11 2019 at 01:49):
@Vadim Peretokin
We have not used it.
But I got it to work.
Working locally from https://github.com/AuDigitalHealth/ci-fhir-stu3 I used Forge to change a profile of Organization thus:
<path value="Organization.address" />
<type>
<code value="Address" />
<profile value="http://hl7.org.au/fhir/StructureDefinition/au-address" />
</type>
<mustSupport value="true" />
I edited an example which claimed conformance to that profile of Organization to fail the address validation and got the following errors in the IGPublisher qa.html
Organization/084bafa0-866d-11e9-bc42-526af7764f64: Organization.address error The address shall at least have text or a line [address.text.exists() or address.line.exists()] Organization/084bafa0-866d-11e9-bc42-526af7764f64: Organization.address.state warning ValueSet https://healthterminologies.gov.au/fhir/ValueSet/australian-states-territories-2 not found Organization/084bafa0-866d-11e9-bc42-526af7764f64: Organization.address.country error Value is 'NZ' but must be 'AU'
Vadim Peretokin (Jul 11 2019 at 08:14):
Ah, ok. So the Java validator then replaces the base profile with that one when making the snapshot, and the .NET one will soon too with 1.3... thank you for testing this @Richard Townley-O'Neill
Michel Rutten (Jul 18 2019 at 13:51):
Hi @Vadim Peretokin, datatype profiles are similar to resource profiles. A profile can constrain the datatype of an element:
1) By including inline constraints on the specific profile element and/or it's children
2) By specifying a datatype profile on the profile element, as @Richard Townley-O'Neill explains.
Option (2) allows you to re-use the same type constraints across multiple profiles.
Note that the FHIR .NET API and Forge support both approaches, and have done so for quite a while (STU3 & R4).
Vadim Peretokin (Jul 18 2019 at 14:03):
Yes that's right, I was unclear on how to actually apply that profile:
https://www.hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.type.profile says it can match any of the profiles, which invalidates it for the purposes of constraining because the datatype will always match the base profile in the specification.
But it looks like the differential overrides the snapshot (and you fixed that bug in the latest .NET release)
Michel Rutten (Jul 18 2019 at 14:21):
Yes, the ElementDefinition.type list property is "special", any type constraints specified in the differential will fully replace/override the original type list, as specified by the base profile. Whereas most other properties inherit omitted information from the base profile. This custom inheritance behavior is necessary to allow constraining polymorphic elements such as Extension.value[x].
Jose Costa Teixeira (Oct 01 2019 at 22:14):
any examples of using a contrained data type in a profile?
I have a profile on element - string320 (string with up to 320 characters) and I want to use it in communication.payload, but I can't get it to work.
Grahame Grieve (Oct 01 2019 at 22:15):
you should just put it in the profile on the type in the elementdefinition, and everything should work
Jose Costa Teixeira (Oct 01 2019 at 22:17):
this?
pasted image
Grahame Grieve (Oct 01 2019 at 22:22):
yes but you need a canonical URL
Jose Costa Teixeira (Oct 01 2019 at 22:23):
i had that - although the profile is actually not yet stored at that url, i.e. that canonical url does not exist yet - does it make a difference?
Grahame Grieve (Oct 01 2019 at 22:24):
no just needs to be in the IG or it's dependencies somewhere
Jose Costa Teixeira (Oct 01 2019 at 22:27):
that is what I had first, I think:
canonical = https://www.ehealth.fgov.be/standards/fhir/StructureDefinition/be-string320
and a file "structuredefinition-be-string320.xml" in my profiles folder
Jose Costa Teixeira (Oct 01 2019 at 22:27):
could it be my data type profile being incorrectly defined? I can track that tomorrow
Jose Costa Teixeira (Oct 26 2019 at 05:57):
I am still unable to successfully publish a constrained datatype - a string wtih <320 characters. I'm sure I'm missing something obvious. Any advice?
Jose Costa Teixeira (Oct 26 2019 at 06:00):
I looked at constrained datatypes in the core spec - positiveInt, markdown - and did it the same way, but it doesn't work.
Grahame Grieve (Oct 26 2019 at 12:24):
what does 'doesn't work' mean?
Jose Costa Teixeira (Oct 26 2019 at 20:09):
Exception generating resource C:\be-core\input\resources\structuredefinition-string320::StructureDefinition/string320: not the right kind of structure to generate schematrons for (02:10.0226)
Grahame Grieve (Oct 27 2019 at 00:16):
ah. can I reproduce this?
Jose Costa Teixeira (Oct 27 2019 at 06:19):
certainly:
https://github.com/hl7-be/be-core
Thomas Tveit Rosenlund (Oct 28 2019 at 10:59):
certainly:
https://github.com/hl7-be/be-core
The profile should still be of type "string" I think.
<type value="string320"/>
Jose Costa Teixeira (Oct 28 2019 at 11:07):
i still get the same issue
Thomas Tveit Rosenlund (Oct 28 2019 at 11:22):
Just a quick question. Can you even profile a primitive datatype in FHIR?
Shure, I have profiled both the HumanName and Address datatypes for no-basis profiles, but never the string datatype directly.
Jose Costa Teixeira (Oct 28 2019 at 11:26):
I guess that is my question too
Michel Rutten (Oct 28 2019 at 12:01):
Yes, FHIR allows you to profile any datatype, including primitives.
Jose Costa Teixeira (Oct 28 2019 at 12:54):
my question then becomes "how" :)
Lloyd McKenzie (Oct 28 2019 at 13:09):
Look at the StructureDefinitions from the core spec to see how the primitives are actually defined
Jose Costa Teixeira (Oct 28 2019 at 13:11):
I looked at the constrained datatypes (positiveInt, Markdown), and did the same (I think) for my string.
these: http://build.fhir.org/structuredefinition-examples.html
Jose Costa Teixeira (Oct 28 2019 at 13:12):
@Lloyd McKenzie Do you mean I should do this not as a profile but as a core definition like I find in the package cache?
Grahame Grieve (Oct 28 2019 at 13:57):
you can do it as a profile. I just forgot to cater for this somewhere in the generation code (you can tell how often people have done it...)
Grahame Grieve (Oct 28 2019 at 13:58):
it's on my list, but I've been at the snomed conference
Grahame Grieve (Oct 28 2019 at 14:31):
I can't run this because you are using a template that you haven't released into the system
Grahame Grieve (Oct 28 2019 at 14:32):
and it should be hl7.be. not hl7be.
Grahame Grieve (Oct 28 2019 at 14:35):
you have a case error there somewhere - xsd:anyUri not xsd:anyURI
Grahame Grieve (Oct 28 2019 at 14:36):
Unable to generate snapshot for https://www.ehealth.fgov.be/standards/fhir/StructureDefinition/be-practitioner: Slicing rules on differential (type:item.resolve() (/open)) do not match those on base (type:$this (unordered/closed)) - disciminator @ Extension.value[x] (http://hl7.org/fhir/StructureDefinition/language)
Grahame Grieve (Oct 28 2019 at 14:40):
in your string profile:
Grahame Grieve (Oct 28 2019 at 14:40):
<derivation value="constraint"/>
Grahame Grieve (Oct 28 2019 at 14:40):
you can't define specializations of primitive data types, only constraints
Jose Costa Teixeira (Oct 28 2019 at 16:39):
<derivation value="constraint"/>
Thank you @Grahame Grieve
Jose Costa Teixeira (Oct 28 2019 at 22:03):
After I profile one element to use string320 instead of string, the IG Publisher still renders this as string:
pasted image
Jose Costa Teixeira (Oct 28 2019 at 22:03):
Jose Costa Teixeira (Oct 28 2019 at 22:04):
Jose Costa Teixeira (Oct 28 2019 at 22:04):
is this a IG Publisher issue?
Grahame Grieve (Oct 28 2019 at 22:18):
yes looks like it to me
Grahame Grieve (Oct 28 2019 at 22:19):
have you committed
Jose Costa Teixeira (Oct 28 2019 at 22:24):
just did
Jose Costa Teixeira (Oct 28 2019 at 22:24):
wait not yet
Jose Costa Teixeira (Oct 28 2019 at 22:45):
ok just pushed
Grahame Grieve (Oct 28 2019 at 23:05):
.. github is blocked on the plane....
Rob Hausam (Oct 28 2019 at 23:06):
yeah, I've seen that happen, too
Grahame Grieve (Oct 29 2019 at 01:38):
ok fixed and new release is on the way
Jose Costa Teixeira (Oct 29 2019 at 05:10):
still presents this as a string, should be string320..
pasted image
Interesting that in the logical model it correctly shows String320
Jose Costa Teixeira (Oct 29 2019 at 06:29):
.. github is blocked on the plane....
So much for in-flight entertainment.. :)
Grahame Grieve (Oct 29 2019 at 06:59):
still presents this as a string
Sounds like you didn't pick up the new IG publisher
Jose Costa Teixeira (Oct 29 2019 at 07:51):
I did.
I looked at the commits to the IG, I could not understand how those changes would resolve this.
Grahame Grieve (Oct 29 2019 at 09:11):
changes where in R5.ProfileUtilities
Grahame Grieve (Oct 29 2019 at 09:12):
about line 2946
Jose Costa Teixeira (Oct 29 2019 at 09:35):
did you push that? I cannot find it in the recent pushes.
Grahame Grieve (Oct 29 2019 at 11:11):
https://github.com/hapifhir/org.hl7.fhir.core/commit/cc496623a6533aa937c25d9baa00082563efafcb
Jose Costa Teixeira (Oct 29 2019 at 13:50):
ok. Sorry, i was looking at fhir-ig-publisher only and thre was something weird on my machine.
It works now, although it is still rendered differently:
Jose Costa Teixeira (Oct 29 2019 at 13:51):
on the profile:
pasted image
Jose Costa Teixeira (Oct 29 2019 at 13:52):
pasted image
This is in the logical model
Grahame Grieve (Nov 08 2019 at 05:04):
is this sorted now?
Jose Costa Teixeira (Nov 08 2019 at 06:45):
I'm checking it with the latest publisher
Jose Costa Teixeira (Nov 08 2019 at 06:45):
I will know in 3 mins
Jose Costa Teixeira (Nov 08 2019 at 06:49):
it's as before: constraining data types is working fine.
Jose Costa Teixeira (Nov 08 2019 at 06:49):
the rendering is still different between the logical model and the profile
Jose Costa Teixeira (Nov 08 2019 at 06:49):
I don't know if this is intended. If not, it is just cosmetic so I did not really care about it.
Grahame Grieve (Nov 11 2019 at 06:40):
hmm how do I reproduce it?
Last updated: Apr 12 2022 at 19:14 UTC
