purge (BETA)
We have added an endpoint to our FHIR servers for DSTU2, STU3, and R4 to delete resources for a specific FHIR version under a single 1up user ID for which a client ID has authority to do so. Users can choose to delete ALL resources, or target specific resource(s) to be purged using an _type parameter and or _before parameter (see below).
This operation also deletes all Resource
_history versions.This is a hard delete of FHIR resources for the given 1up user and this operation should be treated with extreme caution. The delete cannot be undone and data is not able to be recovered once initiated
You can access this endpoint using either a Bearer token, or using header-based authentication.
The client ID and secret you use in the request defined below must have created the 1up user ID which you are attempting to purge data from. In other words, you can't purge the data for a 1up user that you didn't create under your own app (client ID / secret).
Further, without _type and or _before specification, this endpoint defaults to deleting all the FHIR resources (all types) for the given 1up user for a particular FHIR version (e.g., R4). If _type parameter is used, only specified resource(s) by resource type will be purged. If _before parameter is used, and the
meta.lastUpdated date of any given resource is strictly less than (<) the date passed into the _before filter, then those specific resource(s) will be purged (i.e. if the date 2022-05-10 is passed into the _before filter, all resources with a meta.lastUpdated date before but not equal to 2022-05-10 will be purged). In either case, purge will NOT delete the 1up user itself, which will continue to exist, just without the deleted FHIR resources after the purge.Known limitation: using purge to delete all the resources in a user with a large volume of resources (e.g., for 400K patients) will NOT work since the synchronous request can only run for 30 seconds before timing out. We will be introducing a separate asynchronous endpoints to handle larger volumes in the future.
When you receive a timeout resources are deleted before the request timed out. So in theory you can run the same purge several consecutive times until the amount of remaining resources to purge can be deleted within the 30 second time limit
To get an access token, please see our Auth APIs:
delete
https://api.1up.health/{fhirVersion}
/purge
Deletes all resources for given fhirVersion (dstu2, stu3, r4) for a single oneup user
curl --location --request DELETE 'https://api.1up.health/r4/purge' \
--header 'Authorization: Bearer zzzz'
You can also use the
oneup_user_id for a given user as a header. To obtain the oneup_user_id given an app_user_id see our User Management APIs:delete
https://api.1up.health/{fhirVersion}
/purge
Deletes all resources for given fhirVersion (dstu2, stu3, r4) for a single oneup user
curl --location --request DELETE 'https://api.1up.health/r4/purge' \
--header 'client_id: xxx' \
--header 'client_secret: yyy' \
--header 'x-oneup-user-id: 11111'
Last modified 6mo ago