You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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
andWhen not to use FHIR bundles
in Google Healthcare APIThis 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 descriptionprototype
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 neededdependences
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 HAPI FHIR Service has an equivalent import
See #23 end-to-end for current implementation of fhir import
Bundle contents and processing
See #25
The text was updated successfully, but these errors were encountered: