Stream: bulk data
Topic: summary and progress
Josh Mandel (Jan 28 2018 at 20:40):
Hi All! Dan and I are started on a Summary + Progress doc.
If you worked on a client or server, please link to your work with a 1-sentence description
Dan Gottlieb (Jan 28 2018 at 20:48):
Also, I posted a draft write up of the bulk data proposal we've been implementing to https://github.com/smart-on-fhir/fhir-bulk-data-docs/blob/master/README.md . Please edit directly for typos or small changes and open issues and pull requests for substantive changes!
Josh Mandel (Jan 28 2018 at 20:57):
Thanks for this writeup!
GET [fhir base]/Patients/[id]/$export
Should say Group/[id] I think?
Josh Mandel (Jan 28 2018 at 21:01):
_outputFormat (string, optional, defaults to application/fhir+ndjson)
We should note that ndjson is a valid shorthand (as json and xml are shorthands, defined in https://www.hl7.org/fhir/valueset-content-type.html
Josh Mandel (Jan 28 2018 at 21:01):
File Requests:
Should we note that "Accept: application/fhir+ndjson" is expected? (Or default?)
Dan Gottlieb (Jan 28 2018 at 21:03):
Fixed Group/[id]
Dan Gottlieb (Jan 28 2018 at 21:07):
_outputFormat already mentioned the shorthand options, but I added the header info to the file request
Phil Langthorne (Jan 28 2018 at 21:10):
@Josh Mandel I agree that /Group/<id> would be better for groups - follows existing FHIR convention whereas AFAIK pluralizing a named endpoint is not specified. @Dan Gottlieb
Dan Gottlieb (Jan 28 2018 at 21:19):
@Phil Langthorne Yup, it was just a typo and should be fixed now
Christiaan Knaap (Jan 28 2018 at 21:28):
Under _type you say: "as well as resources that are helpful in interpreting the patient data such as Organization and Practitioner" - that needs to be more precise. And computable. Maybe a GraphDefinition is more useful than a CompartmentDefinition?
Josh Mandel (Jan 28 2018 at 21:37):
My perspective: I don't think it can be precise or computable.
Josh Mandel (Jan 28 2018 at 21:37):
This is something that every system is likely to handle differently. (I wish we could be more prescriptive.)
Christiaan Knaap (Jan 28 2018 at 21:38):
So how am I to know what to include and not include then?
Josh Mandel (Jan 28 2018 at 21:39):
I think you follow the compartment definition (which is computable) and you might decide to add anything extra if you think clients will need it.
Josh Mandel (Jan 28 2018 at 21:40):
Mostly I don't want systems to feel limited by what's in a computable definition. We have compartments as far as they go, and over time maybe what we should do is expand the compartment definitions in FHIR.
Christiaan Knaap (Jan 28 2018 at 21:40):
OK, that explanation is useful to add then.
Grahame Grieve (Jan 28 2018 at 21:42):
comparments are defined as logical constructs to help people; they're not something that literally exist diretly or can be used in definitional things
Danielle Friend (Jan 28 2018 at 21:44):
Under the Bulk Data Kick-off Request section - can we call out that all requests (either Patient/$export or Group/id/$export) returns everything that the client has security/authorization for? This came from a note on Grahame's blog post - "..returns all data on all patients that the client's account has access to.."
Dan Gottlieb (Jan 28 2018 at 21:58):
@Danielle Friend Added a note to that effect
Brian Postlethwaite (Feb 02 2018 at 16:18):
Scrolling back through this chat not obvious where the most up to date spec with all the tweaks made at the connectathon is... a job for after the WGM?
Dan Gottlieb (Feb 02 2018 at 16:32):
The document at https://github.com/smart-on-fhir/fhir-bulk-data-docs/blob/master/README.md should be up to date - is there something missing?
Brian Postlethwaite (Feb 02 2018 at 16:34):
Thanks so much, will check.
Dan Gottlieb (Feb 02 2018 at 16:35):
Great - please open an issue if there's additional information we should add!
Brian Postlethwaite (Feb 02 2018 at 19:21):
Did we consider a status 302 (redirect) on the submission where no error was encountered? (rather than an 202 accepted)
Dan Gottlieb (Feb 02 2018 at 22:22):
@Brian Postlethwaite , it seems like 202 is a better fit for kicking off an async operation, since there isn't a resource that has moved. Per https://httpstatuses.com :
202 ACCEPTED - The request has been accepted for processing, but the processing has not been completed.
302 FOUND- The target resource resides temporarily under a different URI.
Brian Postlethwaite (Feb 03 2018 at 05:48):
fair deal, browser automatically sends you there. That was all, and not a real consideration.
Christiaan Knaap (Feb 14 2018 at 18:12):
Which is also a reason not to redirect: the server is probably not ready yet, so no point in going there yet.
Brian Postlethwaite (Jan 25 2019 at 05:16):
The thing that it redirects you to is the async status result, not the final product. Its where to keep asking for the status in follow up calls.
Last updated: Apr 12 2022 at 19:14 UTC
