Stream: bulk data
Topic: Operation Name
Dan Gottlieb (Jan 28 2018 at 15:20):
Several folks at the connectathon have pointed out that $everything may not be an ideal operation name to kick off a bulk data export. In particular it seems confusing to have a \Patient\[id]\$everything that generally won't support async and \Patient\$everything that will.
Dan Gottlieb (Jan 28 2018 at 15:20):
We wouldn't change this today, but what do people think about defining the endpoints as \Patient\$export and \Group\[id]\$export (Josh's suggestion) or \Patient\$bulkdata and \Group\[id]\$bulkdata (Jason's suggestion)? Post a message below with $everything, $export or $bulkdata (and optionally a justification) to vote!
Grahame Grieve (Jan 28 2018 at 15:21):
I don't understand this: "In particular it seems confusing to have a \Patient\[id]\$everything that generally won't support async and \Patient\$everything that will."
Grahame Grieve (Jan 28 2018 at 15:21):
and are you just asking about renaming, or are you proposing different semantics?
Dan Gottlieb (Jan 28 2018 at 15:24):
Just renaming - my point is that currently $everything on a single patient is a synchronous request
Grahame Grieve (Jan 28 2018 at 15:25):
only if you ask for it that way
Grahame Grieve (Jan 28 2018 at 15:25):
my server supports async on any GET
Dan Gottlieb (Jan 28 2018 at 15:26):
Sure, but not all servers will support all options on all request types and bulk data requires async support while single patient requests don't
Grahame Grieve (Jan 28 2018 at 15:27):
true. but that doesn't change the semantics
Dan Gottlieb (Jan 28 2018 at 15:30):
Yup, but for clarity I think having an operation that will often only support async be distinct from one that will often only support sync would make sense
Grahame Grieve (Jan 28 2018 at 15:31):
we get into trouble differentiating semantics because they're often implemented differently for performance reasons (though we have done in a few places)
Vladimir Ignatov (Jan 28 2018 at 15:37):
I wonder, if we rename these and give them dedicated async endpoints like ".../$export", then why do we even need to send the "prefer: respond-async" header?
Josh Mandel (Jan 28 2018 at 15:40):
@Grahame Grieve On semantics, I'd think that giving distinct names to frequently-async operations would help with this confusion and lead to more consistent performance, no?
Danielle Friend (Jan 28 2018 at 15:44):
Additionally, $everything is already defined at [base]/Patient/$everything and has different parameters than we're recommending for bulk data.
Danielle Friend (Jan 28 2018 at 15:44):
It also has a different expectation (whether required or implied) that data is returned paged/in a bundle, not in ndjson files.
Danielle Friend (Jan 28 2018 at 15:46):
And.. is it expected that $everything go normative this year with patient? That seems like it would severely limit our ability to mature the bulk data specification on its own timeline.
Grahame Grieve (Jan 28 2018 at 16:14):
- we haven't decided whether $everything goes normative or not.
- Danielle is actually arguing the semantics are different
- but the return expectations are in the mind of the beholder; they're not different for me
- renaming purely for performance might help if there is a sweet spot for differentiation, but it could also be very confusing
Jason Walonoski (Jan 28 2018 at 16:19):
I vote for a different operation name. $bulkdata or $export. The operation is different than $everything -- should have a different name. It also violates the definition of an operation, I think. Can't POST Parameters, for one thing. It is different. Deserves a different name.
Phil Langthorne (Jan 28 2018 at 16:27):
+1 to $export
Grahame Grieve (Jan 28 2018 at 16:41):
@Jason Walonoski I didn't follow parameters issue
Dan Gottlieb (Jan 28 2018 at 16:43):
General question - if we do go with $export, should you be able to call \Patient\[id]\$export in addition to the current \Patient\[id]\$everything to run an async export to ndjson?
Danielle Friend (Jan 28 2018 at 16:48):
@Dan Gottlieb sounds good to me.
Jason Walonoski (Jan 28 2018 at 16:54):
Parameters issue (as I perceive it): http://hl7.org/fhir/STU3/operations.html#executing
You are supposed to be able to execute an operation with a POST of Parameters or a Resource or a GETif it is idempotent. So, right now bulk data fits under the GET/idempotent rule... but is it expected that operations should also support the POST? I may be muddying the waters here.
Grahame Grieve (Jan 28 2018 at 17:23):
servers can choose to support POST - but so what?
Bas van den Heuvel (Jan 29 2018 at 21:47):
my server supports async on any GET
mine too :)
Last updated: Apr 12 2022 at 19:14 UTC
