Stream: bulk data
Topic: naming $export
Josh Mandel (Feb 22 2018 at 19:59):
Also we'd love to get clarify on the naming: to my mind, based on feedback and functionality $export is probably the right choice. We could avoid any conflict with a group-level "$everything" operation by removing the group-level "$everything" operation definition (after all, this didn't exist previously).
The primary goal here is to avoid propagating two different naming schemes -- we'd really like to nail this shut before the next connectathon.
Grahame Grieve (Feb 22 2018 at 22:16):
can we be clear about what we're doing here, and why? How does $export differ from $everything?
Isaac Vetter (Feb 22 2018 at 22:19):
Hey @Grahame Grieve - we're big fans of $export over $everything, because we don't want to create expectations that we don't meet. Until we support all the resources in the Patient compartment, the word "everything" seems misleading.
Grahame Grieve (Feb 22 2018 at 22:21):
and when you do?
Grahame Grieve (Feb 22 2018 at 22:22):
thought that's an inherent problem with any name - the difference between 'everything I have' and 'everything you might want'
Isaac Vetter (Feb 22 2018 at 22:25):
And the $export name (while a bit boring) neatly avoids this possible missed expectation. The actual content and behavior will be the same.
Grahame Grieve (Feb 22 2018 at 22:30):
I'm not sure whether I should think about this as a general proposal to rename $everything, or create a new operation...
Isaac Vetter (Feb 22 2018 at 22:34):
Ahhh. I see. I hadn't considered that. My impression is that this is a new operation. $everything is an awesome operation. /$everything is a really neat idea and clearly has value in copying FHIR databases.
My take is that we're doing something more specific with bulk data.
Josh Mandel (Feb 22 2018 at 22:39):
My take is that $export does a better job of describing the operation we're defining, and it avoids setting misleading expectations. Again, most urgently I just want us to pick one thing :-)
Josh Mandel (Feb 22 2018 at 22:39):
And to answer your initial question Grahame, what we're doing is: "given a group of patients, prepare a set of data about those patients for export."
Dan Gottlieb (Feb 23 2018 at 14:27):
I agree with @Josh Mandel that it would be good to get the $everything vs. $export question settled. Like @Isaac Vetter , my preference is to use the $export operation, since to me (and apparently others) the name implies a supported export subset (rather than all data in the EHR), as well as a guarantee of async support for the request.
Grahame Grieve (Feb 23 2018 at 18:37):
I'm still unsure whether this is a new operation - with the same signature and characteristics, or a just a rename of the existing operation, or just an alias for it
Josh Mandel (Feb 23 2018 at 18:48):
I think you could look at it as a "rename" of the group-level $everything, or as "add $export and remove group-level $everything". It's not an alias (at least, in my view: the whole goal here is to have clarity and a single name).
Grahame Grieve (Feb 23 2018 at 18:59):
is this only about group? what about on patient?
Kurt Ericson (Apr 18 2018 at 07:07):
Was digging through threads on this topic but couldn't find a clear answer...is the intent to provide Patient/$export as well as Patient/$everything? (I get the Group/$export case)...in which case the operation is different but the contents of the output is more or less the same?
Grahame Grieve (Apr 18 2018 at 07:08):
no clear answer yet. I think that the most of the participants in the thread felt that we should have both
Kurt Ericson (Apr 18 2018 at 07:10):
ok, thanks @Grahame Grieve
Josh Mandel (Apr 18 2018 at 12:34):
I think we weren't sure about a need for Patient/$everything, though of course Patient/:id/$everything is still useful.
Kurt Ericson (Apr 18 2018 at 15:38):
@Josh Mandel right, thanks
Last updated: Apr 12 2022 at 19:14 UTC
