prevention-point
prevention-point copied to clipboard
populated visit endpoint
/api/visits/populated/<id>
permissions:
-
retrieve
-
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 single medical table (
POST api/medications
for example)
follow the current admissions paradigm, these will be updated separately. permissions need to be updated across the app.
tables that have the visit_id as a foreign key will change over time (at the very least in development)
I propose that this endpoint will first query a table with a name like medical_tables
which contain string entries corresponding to the name of each model. you then use these to go query each table that that matches the string for the visit id. gather the disparate data, combine into an object along with "VisitWithPopulationSerializer", and return.
If you have a better idea for dynamically querying a changing slate of tables, speak up
hold off on this one there might be no need for a visit endpoint
@MikeyManoguerra what is the status of this?
Hi @sxgormley, This is still an open question. Our end goal has changed slightly, so there will be less instances where multiple programs need their data returned.
However, #251 is definitely something we need. Are these tickets you feel comfortable taking? If you can tackle #251, We can return to this one.
Cheers