-
Notifications
You must be signed in to change notification settings - Fork 36
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
Regions ADR (architecture decision record) #1381
Conversation
This PR is stale. Please review/update it or close it. |
Re-opening this. |
This PR is stale. Please review/update it or close it. |
This PR is stale. Please review/update it or close it. |
This pull request has been linked to Clubhouse Story #2440: Document a Regions ADR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, this was helpful to me. I was just looking at Regions yesterday and realized I don't understand how we handle regions, facilities, and districts. This sheds a bit of light.
doc/arch/012-regions.md
Outdated
|
||
Our mobile app sync has been built around FacilityGroup. As we have grown, syncing all patients within a FacilityGroup loads far too much data -- sometimes tens of thousands of patients. This can overload mobile phones and introduce many UX challenges. Most Simple app users work with hundreds or maybe a thousand of patients over the course of a week, not 10k+. | ||
|
||
In the admin UI, there are many users who want to monitor performance at differnt levels than the district or facility level. Some admin users should have access to levels above or below the FacilityGroup that do not yet exist. For example, in India some users should have reports access at the [state level](https://en.wikipedia.org/wiki/States_and_union_territories_of_India), which is above the district (ie FacilityGroup). The current model does not suppor this, in any sort of clean way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of typos here: differnt and suppor
Story card: ch2440
Because
Our Regions model is a large change, and could use some explanation, even after the fact 😁 . This adds a retroactive architecture decision record to help explain some of the context, motivation, and tradeoffs around our move to the Regions model.