Stream: bulk data
Topic: Cologne Connectathon
Grahame Grieve (Apr 06 2018 at 03:51):
Does anyone have a canned bulk data testing client?
Grahame Grieve (Apr 06 2018 at 03:52):
@Dan Gottlieb ?
Josh Mandel (Apr 06 2018 at 14:32):
BTW @Kurt Ericson , will you other others from the Google Cloud team be attending the Connectathon in May?
Dan Gottlieb (Apr 06 2018 at 14:43):
@Grahame Grieve I'm not aware of any crucible style testing tool (though I think it would be nice to have one), but @Vladimir Ignatov wrote a nodejs client with backend services auth support at https://github.com/smart-on-fhir/sample-apps-stu3/tree/master/fhir-downloader and there are a couple of clients in various stages of development listed at https://github.com/smart-on-fhir/fhir-bulk-data-docs#client-implementations
Kurt Ericson (Apr 06 2018 at 16:40):
@Josh Mandel Not that I know of but I'll check; I'm on vacation that weekend -- I'll send my best wishes to you all from the beach though ;)
Grahame Grieve (Apr 06 2018 at 19:32):
thx
Jenni Syed (May 04 2018 at 17:11):
I'm slightly concerned about how this track may go given the wifi/internet concerns that have been raised :)
Lloyd McKenzie (May 04 2018 at 17:28):
So long as you use peer-to-peer on the connectathon floor (or talk server to server with servers hosted outside the hotel), you'll be fine. But if you use the internet pipe from hotel to external, it might not be a happy experience.
Jenni Syed (May 04 2018 at 17:33):
I'm going to guess most of the bulk data are external to laptop for testing? Could be wrong. I don't think anyone had peer to peer last time
Jenni Syed (May 04 2018 at 17:33):
More: if there's an issue in the data, we often crack open files locally to figure out why
Josh Mandel (May 04 2018 at 17:51):
My general approach is to SSH into a cloud VM for this kind of thing and do all the work from there
Lloyd McKenzie (May 04 2018 at 17:51):
Peer to peer will be working at the hotel (they promised). You may need to "look" remotely rather than trying to download across the limited hotel pipe.
Lloyd McKenzie (May 04 2018 at 17:51):
Believe me, HQ has been doing their best. The fees we're paying for the limited bandwidth we have are already crazy.
Isaac Vetter (May 04 2018 at 21:58):
I definitely appreciate the challenges of contracting with hotels as ISPs.
Our connectathon testing strategy keeps our FHIR server in the cloud / someone else's computer, and that approach has a lot of benefits compared to running locally.
John Moehrke (May 05 2018 at 12:03):
so we should have the connectathons in the cloud...
Grahame Grieve (May 06 2018 at 03:58):
we already do.
Grahame Grieve (May 06 2018 at 03:59):
I'll have a version of my server running locally
Josh Mandel (May 13 2018 at 08:08):
Please review and add to the write-up @Danielle Friend @Dennis Patterson @Eyal Oren @Patrik Sundberg @Toby Hu
Dennis Patterson (May 13 2018 at 08:26):
+1 @Josh Mandel . I added a note around the potential to use asynchronous exchange for other use-cases
Danielle Friend (May 13 2018 at 08:51):
@Josh Mandel Looks good. I added a line about doing more testing with security in place.
Grahame Grieve (May 13 2018 at 09:24):
so I see that we haven't got a task to document $export in the spec. But it seems to me that we're at the point where it makes sense to document this, yes?
Dennis Patterson (May 13 2018 at 09:34):
I think we're getting close to start documenting some asynchronous mechanisms (e.g. Prefer header set to async, 202 response pointing to a Content-Location)... but there are also some aspects of the bulk data spec we haven't yet tested such as integrating SMART backend services spec, deletes for asynchronous requests
Josh Mandel (May 13 2018 at 09:37):
We also haven't worked through retries, status, etc. We've been expecting to gather/implement feedback over the coming months.
Grahame Grieve (May 13 2018 at 09:57):
reading https://github.com/smart-on-fhir/fhir-bulk-data-docs/blob/master/export.md...
Grahame Grieve (May 13 2018 at 09:58):
actually, https://github.com/smart-on-fhir/fhir-bulk-data-docs/blob/master/export.md#bulk-data-status-request
Grahame Grieve (May 13 2018 at 09:58):
what should the accept header be on GET [polling content location] ?
Josh Mandel (May 13 2018 at 09:58):
We obviously don't say. Logically it should be "application/json" I suppose.
Grahame Grieve (May 13 2018 at 09:59):
I think that's the only choice and we should say that
Josh Mandel (May 13 2018 at 10:00):
Good. Added https://github.com/smart-on-fhir/fhir-bulk-data-docs/issues/25
Grahame Grieve (May 13 2018 at 10:01):
thx
John Moehrke (May 13 2018 at 16:13):
One AuditEvent that describes the request. not including the response individual resoures... right? Would be ugly if one needs to record all the resources returned, worse if a export AuitEvent was recorded for each export...
Last updated: Apr 12 2022 at 19:14 UTC
