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

populated visit endpoint #250

Open
MikeyManoguerra opened this issue Mar 20, 2020 · 3 comments
Open

populated visit endpoint #250

MikeyManoguerra opened this issue Mar 20, 2020 · 3 comments
Labels

Comments

@MikeyManoguerra
Copy link
Collaborator

MikeyManoguerra commented Mar 20, 2020

/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

@MikeyManoguerra
Copy link
Collaborator Author

hold off on this one there might be no need for a visit endpoint

@sxgormley
Copy link
Collaborator

@MikeyManoguerra what is the status of this?

@MikeyManoguerra
Copy link
Collaborator Author

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

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

No branches or pull requests

2 participants