FHIR Chat · ElementDefinition type profile · conformance

Stream: conformance

Topic: ElementDefinition type profile


view this post on Zulip Brian Postlethwaite (Apr 04 2018 at 23:59):

While updating the code generation for R4 .net I've noticed that the multi cardinality for profile and target profile is back again.
(was 0..* in dstu2, then 0..1 in stu3, now 0..* again)

view this post on Zulip Grahame Grieve (Apr 04 2018 at 23:59):

yes ;-(

view this post on Zulip Grahame Grieve (Apr 05 2018 at 00:00):

source of many bugs during the publication process

view this post on Zulip Grahame Grieve (Apr 05 2018 at 00:00):

:-(

view this post on Zulip Brian Postlethwaite (Apr 05 2018 at 00:05):

Great, thanks.

view this post on Zulip Brian Postlethwaite (Apr 05 2018 at 00:06):

(And its the last compile issue with the .net fhir client for the update - till I do the full generated code review)

view this post on Zulip Brian Postlethwaite (Apr 05 2018 at 00:15):

And I assume that we just missed updating StructureDefinition.Url from uri to canonical?

view this post on Zulip Grahame Grieve (Apr 05 2018 at 00:16):

no that was deliberate

view this post on Zulip Brian Postlethwaite (Apr 05 2018 at 00:16):

They can be compared though right?

view this post on Zulip Grahame Grieve (Apr 05 2018 at 00:16):

yes

view this post on Zulip Lloyd McKenzie (Apr 05 2018 at 04:41):

canonical is allowed to contain values with the syntax "http://someurl.com|version". StructureDefinition.url is restricted to "http://someurl.com"

view this post on Zulip Lloyd McKenzie (Apr 05 2018 at 04:42):

So the comparison process needs to check for the presence of a business version in the canonical string

view this post on Zulip Michel Rutten (Apr 09 2018 at 08:58):

Not looking forward to refactoring the snapshot generator to deal with multiple type profiles... :worried:

view this post on Zulip Ewout Kramer (Apr 09 2018 at 10:05):

Not looking forward to refactoring the snapshot generator to deal with multiple type profiles... :worried:

Don't worry too much, it's rather an OR (now done with multiple typeRefs) than an AND (as it was in DSTU2)

view this post on Zulip Grahame Grieve (Apr 09 2018 at 10:05):

it's still a lot of work

view this post on Zulip David Hay (Apr 09 2018 at 22:54):

What was the reason for the change?

view this post on Zulip Marten Smits (Apr 11 2018 at 12:22):

So if type.profile and type.targetProfile are both 0..*, and it is an OR instead of an AND. Does that mean if I have a Reference-NL type and a Reference-DE type, and a TargetProfile nl-core-patient OR de-core-patient. That I get the following options:

Reference-NL(nl-core-patient)
OR
Reference-NL(de-core-patient)
OR
Reference-DE(nl-core-patient)
OR
Reference-DE(de-core-patient)

??

view this post on Zulip Grahame Grieve (Apr 11 2018 at 12:29):

yes pretty much but the profile and targetProfile are pretty orthogonal, so I haven't been bothered by that

view this post on Zulip Marten Smits (Apr 11 2018 at 13:14):

And is repeating targetProfile specifying one can reference a nl-core-patient OR nl-core-practitioner encouraged above repeating the type backbone element?

view this post on Zulip Grahame Grieve (Apr 11 2018 at 13:21):

type codes must be unique now - so more than just encouraged

view this post on Zulip Marten Smits (Apr 11 2018 at 13:22):

haha fair enough, makes sense. thanks!


Last updated: Apr 12 2022 at 19:14 UTC