ACED-IDP / submission

Submit FHIR based data into a Gen3 Commons
1 stars 0 forks source link

Bundle Submission #9

Open bwalsh opened 1 year ago

bwalsh commented 1 year ago

use case

As a ACED developer, in order to submit and maintain meta data, it would be useful to have an openapi defined service to allow server and client side engineers to develop services.

As an ACED submitter, when I submit data, the fhir import job allows me to "upsert" records at scale. However, this mechanism does not allow me to DELETE orphaned or miscreant records.

summary

FHIR servers (Google Healthcare API and HAPI in this example) implement two separate and distinct ways to load data:

See When to use FHIR bundles and When not to use FHIR bundles in Google Healthcare API

This task defines the second Bundle processing, an implementation of a very narrow subset of the FHIR REST API. i.e. POST [base]/Bundle For example, see HAPI Bundle description

prototype

A prototype Flask application exists to illustrate the Bundle endpoint. An openapi document describes this operation. Specifically, an implementation of processing each Bundle entry is needed

image

dependences

alternatives

Existing sower.jobs api The current sower.job effectively implements the equivalent of google's fhirStore.import with contentStructure of type RESOURCE where:

The source file contains one or more lines of newline-delimited JSON (ndjson). Each line is a single resource.

The HAPI FHIR Service has an equivalent import

See #23 end-to-end for current implementation of fhir import

Bundle contents and processing

See #25

matthewpeterkort commented 2 months ago

Are we implementing PUT or POST? in this doc it says to use POST, but in the code PUT was being used.

I'm assuming since we talked about this being an upsert operation, PUT is more appropriate.

bwalsh commented 2 months ago

Exactly! PUT is more appropriate