Lloyd McKenzie

In theory, the confllict doesn't occur until the user applies the suggestion - and the user could do that in any order whatsoever. One possibility is that as soon as...

What Isaac actually proposed where it says _context...id_ before Github intervened was `context...id` I'd be in favor of this. The reason for putting resource names in is to allow you...

Right. If the context element is limited to a single resource type, no need to include the resource name in the path (unless there was some reason we wanted consistency...

I'm not sure "remove the need to make their own FHIR queries" is necessarily an illegitimate requirement. It may be that EHRs will choose not to satisfy the prefetch, but...

It's not totally clear to me that convenience doesn't itself have merit or that doing so necessarily constitutes bad API design, though I'm open to that perspective. One challenge that...

The base usecase for prefetch - wanting to provide optimal access to data that may already be in memory, minimizing queries when providing data to multiple hook services, etc. all...

I haven't seen more discussion - how do we move this forward?

Poking on this. There was a proposed disposition, but it never moved forward. @brynrhodes @isaacvetter - can we take this up at the Thur. Q4 session?

It would be the same, just the include would change. i.e. "&_include=MedicationRequest.medication". If somehow a hook had a context that could be a mixture of MedicationRequest and MedicationStatement instances, then...

Poking on this one to see if we can get discussion started. It would now be relevant to order-select and order-sign hooks. The DeviceUseRequest resources is there for DSTU2 but...