FHIR Chat · StructureDefinition.context · conformance

Stream: conformance

Topic: StructureDefinition.context


view this post on Zulip Ewout Kramer (Sep 28 2017 at 11:22):

Michel pointed out to me that Lloyd assumed StructureDefinition.context can be any kind of text. Indeed, this element is a string- but I doubt very much tools would expect prose here. The intention - as far as I know - is for this element to contain a path (at least when the context type is Resource or Datatype). When would narrative be acceptable (if at all)?

view this post on Zulip Michel Rutten (Sep 28 2017 at 11:37):

Sorry for the confusion, here's Lloyd's earlier comments on extension context:

https://chat.fhir.org/#narrow/stream/implementers/subject/extensions

Lloyd McKenzie 04:35
"...If contextType is "resource", then the context must be a resource name or path. If contextType is "datatype" then the context must be a data type name or path. If contextType is extension, then the context must be the extension URL. I'm actually not sure how to refer to a sub-element within a complex extension..."

https://chat.fhir.org/#narrow/stream/implementers/subject/extensions.20Patient.20Name.20Parts

"2. Context must be a specific Resource path. It's computable."

So the exception is when contextType equals extension, then the context property apparently should specify a canonical url instead of an element path.

view this post on Zulip Ewout Kramer (Sep 28 2017 at 11:40):

Ok, so I agree on all that ;-) Maybe it wasn't Lloyd who thought it could by any text, then?

view this post on Zulip Michel Rutten (Sep 28 2017 at 11:42):

Found it, turns out the comment wasn't by Lloyd:

"Grahame Grieve 01:32
the conext can be any meaningful string, where meaning is specified by the contextType"

view this post on Zulip Ewout Kramer (Sep 28 2017 at 11:44):

Funny, those 01:32 timestamps. Makes ik look like "The Gospel according to...."

view this post on Zulip Ewout Kramer (Sep 28 2017 at 11:45):

That's ok, as long as "meaningful" here means "a FhirPath(?) path" for type={resource,datatype}, "uri" for type={extension} etc....

view this post on Zulip Chris Grenz (Sep 28 2017 at 12:52):

@Ewout Kramer does FHIRPath have any kind of hi/low complexity categories? As in, a context must be a simple FHIRPath expression? Or is the whole syntax always available?

view this post on Zulip Chris Grenz (Sep 28 2017 at 12:54):

Also, note that URIs may include locators:

http://example.com/StructureDefinition/my-extension#Extension.extension:firstPart.valueString

Is this legal for context on extensions?

view this post on Zulip Ewout Kramer (Sep 28 2017 at 12:55):

@Ewout Kramer does FHIRPath have any kind of hi/low complexity categories? As in, a context must be a simple FHIRPath expression? Or is the whole syntax always available?

The notion of "flavors" of FHIRPath has been popping up a few times....e.g. in GF#13711...

view this post on Zulip Ewout Kramer (Sep 28 2017 at 12:56):

SearchParameters, discriminator paths, extension context....

view this post on Zulip Chris Grenz (Sep 28 2017 at 12:56):

:+1:

view this post on Zulip Chris Grenz (Sep 28 2017 at 12:57):

Thinking about writing a native node.js snapshot generator/validator and FHIRPath makes my life very difficult

view this post on Zulip Ewout Kramer (Sep 28 2017 at 12:59):

Just a snapshot->FHIRPath translator and then an efficient FHIRPath engine would do ;-) I had some philosophical discussions with Bryn about additions to FHIRPath to make the structural constraints in an SD translateable to FHIRPath. But your error reporting to the user would probably be absymal. Anyway, don't want to punish your brains any more than necessary ;-)

view this post on Zulip Ewout Kramer (Sep 28 2017 at 13:01):

Also, note that URIs may include locators:

http://example.com/StructureDefinition/my-extension#Extension.extension:firstPart.valueString

Is this legal for context on extensions?

Have not given that a thought yet....but in the links Michel included above, I see Lloyd wonder about how to specify a context within an extension. This might be it..

view this post on Zulip Chris Grenz (Sep 28 2017 at 13:06):

There are tiers of functionality (I think) in what profiles do and how they can be applied. Things like:
- Converting a profile into search criteria to apply the profile to the whole server
- Using profiles (with slices) to create a better specified schema (Patient with an "officialName" element)
- Stream parsing of resources to avoid having to keep large resources in-memory
Because there aren't (yet) public examples of any of these kinds of things, it's tempting to make really complex FHIRPath constraints, and those will keep these profiles from being used in highly optimizing parsers

view this post on Zulip Lloyd McKenzie (Sep 28 2017 at 14:50):

We should certainly document how to point to sub-elements within an extension. Chris, do you want to submit a tracker on that?

view this post on Zulip Michel Rutten (Sep 28 2017 at 14:54):

I seem to remember that I wrote some logic in Forge or .NET API before concerning url's that walk into a complex extension using anchor notation. I think this aligns with the example above, but I'll check.

view this post on Zulip Grahame Grieve (Oct 03 2017 at 03:04):

I certainly intended for the context string to reference an element but it's id not by it's path - e.g. not FHIRPath. Not here.

view this post on Zulip Grahame Grieve (Oct 03 2017 at 03:06):

context is either an element but it's id, or it's canonical url.

view this post on Zulip Grahame Grieve (Oct 03 2017 at 03:06):

it could be cleaner to make it always a full URL that identifies an element authoritatively.

view this post on Zulip Michel Rutten (Oct 03 2017 at 10:38):

So if I understand correctly, it is valid for the context property to specify an element id, e.g. "Patient.identifier:ssn"?

view this post on Zulip Grahame Grieve (Oct 03 2017 at 11:44):

that would be problematic - which :ssn? that's why I was thinking about making it a full url

view this post on Zulip Michel Rutten (Oct 03 2017 at 12:03):

So if I understand correctly, this would allow an extension definition to state: I am designed to be used in profiles derived from a specific base profile and on a specific slice? Advanced, but I see how this might be useful.

view this post on Zulip Grahame Grieve (Oct 03 2017 at 12:08):

yes could do that. I would encourage to be a little more general, but people do want to be extremely specific

view this post on Zulip Michel Rutten (Oct 03 2017 at 12:10):

Agreed. So maybe we should not proactively change this until there is sufficient demand from the community?

view this post on Zulip Grahame Grieve (Oct 03 2017 at 12:11):

going normative in R4.

view this post on Zulip Michel Rutten (Oct 03 2017 at 12:15):

I see, then I guess we have to define the proper format now.

view this post on Zulip Chris Grenz (Oct 03 2017 at 19:44):

Format is set when we locked the format of elementdefinition.id.

http://example.com/my-us-patient#Patient.identifier:ssn


Last updated: Apr 12 2022 at 19:14 UTC