Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bundle Submission #9

Open
bwalsh opened this issue Oct 26, 2023 · 2 comments
Open

Bundle Submission #9

bwalsh opened this issue Oct 26, 2023 · 2 comments

Comments

@bwalsh
Copy link
Collaborator

bwalsh commented Oct 26, 2023

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:

  • the first - import - we have already implemented via sower see "alternatives" below
  • the second - Bundle is described here

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

  • FHIR bundle. Creating/updating/deleting a set of resources on a server as a single operation
  • REST endpoint. For each entry in the bundle, the interaction creates a new current version for an existing resource or creates an initial version if no resource already exists for the given id.
  • g3t bundle creation Existing code that creates a Bundle of DELETE transactions for orphaned meta records
    • the mechanism to determine when to use a Bundle vs use fhir import needs to be documented. Currently, the only gap is As a submitter, when I need to remove metadata, I need a mechanism in g3t to remove those records

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

@bwalsh bwalsh changed the title Submission Service Bundle Submission Endpoint Jul 11, 2024
@bwalsh bwalsh changed the title Bundle Submission Endpoint Bundle Submission Jul 11, 2024
@matthewpeterkort
Copy link
Collaborator

matthewpeterkort commented Aug 26, 2024

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
Copy link
Collaborator Author

bwalsh commented Aug 26, 2024

Exactly! PUT is more appropriate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants