Stream: Da Vinci
Topic: References in Parameters
Bryn Rhodes (Jul 19 2018 at 20:06):
Based on this note I think that using relative paths in the resources in the Parameters is non-conformant. @Nikolai Schwertner @Eric Haas, do you have the same read? So we'd expect to see absolute URLs in the resources being exchanged.
Eric Haas (Jul 19 2018 at 20:16):
I agree, but I don't understand the need for absolute references either since I don't know what data reciever is going to do with them. all you need to know the resource Type. we may be missing a formal Graph definition ( I admit I didn't look at the MRP Measure profile - does that define it and can you send me link? ) or back to using a bundle instead as an implicit graph. Good catch. and great to have @Nikolai Schwertner implementing as we create the IG.
Bryn Rhodes (Jul 19 2018 at 20:20):
No, I think we still use parameters, but I do wonder whether we can use transient ids in a Parameters resource. @Lloyd McKenzie any thoughts? I assume this isn't the only place people would want to do that.
Eric Haas (Jul 19 2018 at 20:27):
My point is at least in MRP assuming the correct resources instances are present you only need to know the resource type to process so the references matter only as a validation.
Bryn Rhodes (Jul 19 2018 at 20:27):
Yep, totally agree
Lloyd McKenzie (Jul 19 2018 at 20:51):
We wouldn't use relative paths, we'd us local ids - so "#foo"
Lloyd McKenzie (Jul 19 2018 at 20:53):
Though that doesn't totally work either because they're in the context of the parent... @Grahame Grieve ?
Eric Haas (Jul 19 2018 at 20:57):
?"context of the parent"?
Bryn Rhodes (Jul 19 2018 at 21:00):
Right, the parent in a Bundle is the Bundle so you can resolve it, or in a contained element is the containing resource, but in a Parameters, that documentation explicitly says you can't do that.
Eric Haas (Jul 19 2018 at 21:01):
so Why not go back to a Bundle?
Bryn Rhodes (Jul 19 2018 at 21:09):
Pass a Bundle as the second parameter? Or as the only Parameter?
Eric Haas (Jul 19 2018 at 22:02):
only one
Eric Haas (Jul 19 2018 at 22:03):
since you need the rel urls to work
Eric Haas (Jul 19 2018 at 22:04):
collection become just a return bundle
Bryn Rhodes (Jul 19 2018 at 22:11):
I wonder if this is an unintended consequence of this change: GF#17273
Bryn Rhodes (Jul 19 2018 at 22:11):
Because now in MeasureReport, we effectively can't reference transient resources, unless we make them contained.
Bryn Rhodes (Jul 19 2018 at 22:11):
Which is, I suppose, another option.
Lloyd McKenzie (Jul 19 2018 at 22:19):
Contained is to be used when resources cannot stand alone and aren't expected to ever be referenced by anything else. That wouldn't hold here.
Bryn Rhodes (Jul 19 2018 at 22:23):
Agree, just trying to figure out how to support the case where the Provider is trying to use $submit-data but doesn't necessarily want to say "I actually have a Task resource at this URL", they just want to communicate that this is what it would look like if I did.
Lloyd McKenzie (Jul 19 2018 at 22:26):
I don't understand that. You have a Task or you don't. It may or may not have a RESTful URL. And it may have an intent of proposed or planned rather than requested, but it's still a Task.
Bryn Rhodes (Jul 19 2018 at 22:28):
Okay, so if I send you a MeasureReport and it has a reference to a Task by an absolute URL, it's not non-conformant for me to return a 404 when you attempt to resolve that resource reference against my server?
Bryn Rhodes (Jul 19 2018 at 22:28):
Just trying to make sure I understand.
Lloyd McKenzie (Jul 19 2018 at 22:28):
If the task doesn't exist on your server, it shouldn't have a URL
Lloyd McKenzie (Jul 19 2018 at 22:29):
It can (and should) just be a urn:uuid as the fullUrl
Bryn Rhodes (Jul 19 2018 at 22:29):
Ah, gotcha.
Lloyd McKenzie (Jul 19 2018 at 22:29):
(Should have said "If the task doesn't exist on some server...")
Grahame Grieve (Jul 19 2018 at 23:05):
so, umm, I've missed some context here.... can someone explain with examples?
Eric Haas (Jul 19 2018 at 23:08):
### Examples
Scenario: Provider X submits MRP data for Patient Z to Payer Z
Assumptions: ...TODO...
#### Request using POST Syntax
POST [base]/MeasureReport/measure-mrp/$submit-data
Request body
{
"resourceType":"Parameters",
"parameter":[
{
"name":"measurereport",
"resource":"{"resourceType": "MeasureReport",
...}
},
{
"name":"resource",
"resource":"{"resourceType": "Task",
...}
},
{
"name":"resource",
"resource":"{"resourceType": "Patient",
...}
},
{
"name":"resource",
"resource":"{"resourceType": "Location",
...}
},
{
"name":"resource",
"resource":"{"resourceType": "Practitioner",
...}
},
{
"name":"resource",
"resource":"{"resourceType": "Organization",
...}
},
{
"name":"resource",
"resource":"{"resourceType": "Encounter",
...}
Grahame Grieve (Jul 19 2018 at 23:11):
ok, and what's the question?
Eric Haas (Jul 19 2018 at 23:15):
If MeasureReport can't reference Task directly in the Parameters resource. So if we want a reference that resolves what to do. I suggested go back to bundle. I'm not sure what Bryn was suggesting
Eric Haas (Jul 19 2018 at 23:16):
I think he was suggesting the resources where created on the fly and are not persisted anywheres
Grahame Grieve (Jul 19 2018 at 23:16):
MeasureReport needs to reference the Task?
Eric Haas (Jul 19 2018 at 23:17):
Technically it does not for the MRP use case since its tightly defined what is to be sent. But not sure about the general case.
Grahame Grieve (Jul 19 2018 at 23:18):
so the general case is that the task resource has a an id of task1
Grahame Grieve (Jul 19 2018 at 23:18):
the MeasureReport refers to it as "reference": "Task/task1"
Eric Haas (Jul 19 2018 at 23:18):
Y
Grahame Grieve (Jul 19 2018 at 23:18):
of course that can be a generated UUID
Grahame Grieve (Jul 19 2018 at 23:19):
the tricky bit is that when you put a resource in a parameters, you have to say which other parameter location(s) the resource could resolve to in the Parameters
Grahame Grieve (Jul 19 2018 at 23:19):
if it doesn't resolve in the parameters, then you fall back to general resolution rules
Eric Haas (Jul 19 2018 at 23:19):
yes and as Bryn pointed out is not supported: https://chat.fhir.org/#narrow/stream/128-DaVinci/subject/References.20in.20Parameters/near/165935
Grahame Grieve (Jul 19 2018 at 23:20):
what is not supported?
Eric Haas (Jul 19 2018 at 23:20):
http://build.fhir.org/parameters.html#ids
Eric Haas (Jul 19 2018 at 23:21):
last row
Grahame Grieve (Jul 19 2018 at 23:22):
umm, I'm not seeing what is not supported...
Eric Haas (Jul 19 2018 at 23:22):
"that resources cannot reference content in another resource using an internal reference (except for references inside contained resources)"
Eric Haas (Jul 19 2018 at 23:24):
Unless we have misinterpreted that part.
Grahame Grieve (Jul 19 2018 at 23:26):
I didn't think we were talking about internal references
Grahame Grieve (Jul 19 2018 at 23:26):
that's why I said "reference" : "Task/task1"
Eric Haas (Jul 19 2018 at 23:32):
I thought that was what internal references meant here
Eric Haas (Jul 19 2018 at 23:32):
reference inside the Parameters resource between parameters
Eric Haas (Jul 19 2018 at 23:34):
So where is the topic of referencing resources within Parameters discussed.
Lloyd McKenzie (Jul 19 2018 at 23:34):
For resources inside a Parameters instance, what's the fullUrl?
Grahame Grieve (Jul 19 2018 at 23:35):
internal reference = "reference" : "#a234234"
Grahame Grieve (Jul 19 2018 at 23:35):
there is no fullUrl. only relative reference resolution
Lloyd McKenzie (Jul 19 2018 at 23:36):
So when you pass something to an operation, you can't indicate where the data actually lives? So if something wants to query more information about a passed argument, it can't?
Grahame Grieve (Jul 19 2018 at 23:37):
not in the infrastructure, no
Grahame Grieve (Jul 19 2018 at 23:37):
has to be a parameter, I guess
Eric Haas (Jul 19 2018 at 23:37):
or a Bundle
Grahame Grieve (Jul 19 2018 at 23:37):
could do that too
Grahame Grieve (Jul 19 2018 at 23:38):
but we're clear about internal, relative and absolute references y?
Lloyd McKenzie (Jul 19 2018 at 23:44):
Relative references are only allowed between things that have the same fullUrl - and we don't know what the fullUrl of the things in Parameters are
Grahame Grieve (Jul 19 2018 at 23:45):
"Relative references are only allowed between things that have the same fullUrl" - you have evidence for that?
Lloyd McKenzie (Jul 19 2018 at 23:48):
That's the rule in Batch and in regular REST transactions.
Lloyd McKenzie (Jul 19 2018 at 23:50):
You can't have a relative reference in a regular REST operation if the resource lives on a different server than the referencing resource. And in Batch, relative references can only happen if the resource has the same base. That's what the documented resolution rules say.
Lloyd McKenzie (Jul 19 2018 at 23:51):
We don't have any resolution rules for Parameters
Grahame Grieve (Jul 19 2018 at 23:57):
first paragraph: wrong. So far as I can see
Lloyd McKenzie (Jul 19 2018 at 23:58):
First paragraph of what?
Grahame Grieve (Jul 19 2018 at 23:58):
I can't find either of these explicitly stated:
- You can't have a relative reference in a regular REST operation if the resource lives on a different server than the referencing resource.
- And in Batch, relative references can only happen if the resource has the same base.
Grahame Grieve (Jul 19 2018 at 23:59):
I think you've extrapolated and done so slightly wrongly
Grahame Grieve (Jul 19 2018 at 23:59):
but we do have a problem:
If the fullUrl starts with urn:uuid: or urn:oid:, then append the id to the base URL
Grahame Grieve (Jul 19 2018 at 23:59):
what base URL?
Lloyd McKenzie (Jul 19 2018 at 23:59):
http://build.fhir.org/references.html#literal: a relative URL, which is relative to the Service Base URL, or, if processing a resource from a bundle, which is relative to the base URL implied by the Bundle.entry.fullUrl (see Resolving References in Bundles)
Grahame Grieve (Jul 20 2018 at 00:31):
soI did not not think to look there, but you are extrapolating. but we could certainly clarify resolution in a parameters resource. The key thing is that you can only resolve using relative references, and only to specified parameters
Lloyd McKenzie (Jul 20 2018 at 01:00):
Extrapolation is all you can do in the absence of specific guidance :)
If you can only resolve using relative references, does that mean that we can't assume that any of the relative references are or can refer to elements on the server on which the operation is being invoked? If it can include a mixture, how do we differentiate? I'm beginning to think that having fullUrl on Parameters.parameter (required and allowed only if parameter.resource is present) would be a good idea.
Grahame Grieve (Jul 20 2018 at 01:01):
in the absence of guidance it creates less confusion if you admit the absence rather than stating that your expectations are law
Grahame Grieve (Jul 20 2018 at 01:02):
what I proposed above is that for some parameters, you indicate that they can resolve in other parameters, and that either way you fall back to local resolution rules
Grahame Grieve (Jul 20 2018 at 01:02):
the difference with Bundle is that we anticipate cross server resolution is necessary. I don't see that this is an issue for operations
Lloyd McKenzie (Jul 20 2018 at 01:07):
Ok, so you treat all elements in the Parameters instance as potentially resolvable within the instance. It they don't, you expect them to resolve on the target server. If they don't resolve there, it's an error. If they resolve in both places (in the instance and on the server), the resource in the Parameters is interpreted to be the same as the one on the server?
Lloyd McKenzie (Jul 20 2018 at 01:07):
(though possibly a different version)
Grahame Grieve (Jul 20 2018 at 01:07):
well, I think it needs to be specified on the parameters in the defintion - it depends on why a parameter is provided.
Grahame Grieve (Jul 20 2018 at 01:07):
but parameters overrides if there's a match
Lloyd McKenzie (Jul 20 2018 at 01:09):
I'm not thrilled with the idea that resolution behaves differently based on non-computable rules. That makes general-purpose validation of the instance impossible
Grahame Grieve (Jul 20 2018 at 01:09):
can add it to operation definition if we want
Lloyd McKenzie (Jul 20 2018 at 01:11):
So "local-only" (in Parameters, not on server), "server-only", "both", "either"?
Grahame Grieve (Jul 20 2018 at 01:11):
nominate which parameter might be a place to look for resolution.
Grahame Grieve (Jul 20 2018 at 01:12):
there's places where you don't want to resolve because of the operation semantics
Grahame Grieve (Jul 20 2018 at 01:12):
Eric's example above: "resource" is provided to be a resolve target
Lloyd McKenzie (Jul 20 2018 at 01:12):
But that could be different for different references - that gets evil fast.
Grahame Grieve (Jul 20 2018 at 01:13):
don't see that would matter
Grahame Grieve (Jul 20 2018 at 01:13):
just list the possible resolutions.
Grahame Grieve (Jul 20 2018 at 01:13):
anyway, should be an extension for now
Lloyd McKenzie (Jul 20 2018 at 01:13):
So "these are the parameter paths where some of the references in this resource might resolve to"?
Grahame Grieve (Jul 20 2018 at 01:14):
y something like that
Grahame Grieve (Jul 20 2018 at 01:14):
else server resolves locally. and decides what to do if there's no match
Lloyd McKenzie (Jul 20 2018 at 01:14):
I think just saying "might resolve somewhere in the Parameters instance" should be sufficient. It's not like it's hard to check across everything in the resource.
Lloyd McKenzie (Jul 20 2018 at 01:15):
The question is knowing whether it's supposed to resolve or not
Lloyd McKenzie (Jul 20 2018 at 01:16):
Or I guess more useful would be "Is there an expectation this parameter will be pointed to by something" and if so, from where.
Grahame Grieve (Jul 20 2018 at 01:17):
y nicer that way round
Lloyd McKenzie (Jul 20 2018 at 01:32):
Last updated: Apr 12 2022 at 19:14 UTC
