-
Notifications
You must be signed in to change notification settings - Fork 15
PHASE 2 Endpoint sketch
For the next phase of the backend, being able to query the backend for medical data is the next hurdle. I want to make some tickets that are more manageable.
this also does not include the permissions portion, but just data fetching. the permissions should be able to plug in as class decorators
These would exist for each table or form related to a visit that is sensitive data
/api/urinedrugscreen/
- GET all
- GET 1
- POST
- UPDATE 1
-
/api/urinedrugscreen/populated/(populated is the best i can come up with but open to better ideas) - GET
- GET 1
a second endpoint which populates the visit information and participant information . this can be read only and thus not have to worry about complex splitting and recombining
/api/visits/populated/<id>
-
GET 1
-
This endpoint can return all the medical data for a particular visit.
-
It should probably not have a get all feature because that would be expensive.
-
this endpoint also would be internal provider or admin only.
-
This could be used to populate update forms, but any update requests would be sent back to the respective PATCH/PUT
/api/urinedrugscreen/.
/api/participants/populated/<id>
- GET 1 same as above but for searches on the user
I think this setup provides a way to protect sensitive data from un-permissioned 3rd party providers.
low level, 'all access' to signed in users endpoints:
/api/participants//api/visits/
endpoints for admin, internal providers, and RELEVANT external providers:
/api/urinedrugscreen//api/urinedrugscreen/populated/
endpoints for admin and internal providers only:
/api/visits/populated/<id>/api/participants/populated/<id>
is this correct? any thoughts? I want to make tickets for them so other people can contribute