# Structuring multiple organizations at the same location

**URL:** <https://forum.openreferral.org/t/structuring-multiple-organizations-at-the-same-location/531>\
**Category:** Data Management\
**Created:** [May 20, 2024, 3:16pm UTC](https://forum.openreferral.org/t/structuring-multiple-organizations-at-the-same-location/531 "2024-05-20T15:16:11Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![skyleryoung](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.openreferral.org/skyleryoung/32/212_2.png) [@skyleryoung](https://forum.openreferral.org/u/skyleryoung)\
**Post date:** [May 20, 2024, 3:16pm UTC](https://forum.openreferral.org/t/structuring-multiple-organizations-at-the-same-location/531/1 "2024-05-20T15:16:11Z")

</div>

I’ve run into a case where clients are defining multiple organizations at the same location. Which makes sense; organizations have the same use-case as services where locations are concerned.

Is there a use-case for adding an organization\_at\_location table in HSDS? Or is this a case where the exchange format is intentionally more opinionated than a resource management system should be?

---

<div class="post-metadata">

**Author:** ![DrewW](https://avatars.discourse-cdn.com/v4/letter/d/e99b99/32.png) [@DrewW](https://forum.openreferral.org/u/DrewW)\
**Post date:** [May 20, 2024, 5:28pm UTC](https://forum.openreferral.org/t/structuring-multiple-organizations-at-the-same-location/531/2 "2024-05-20T17:28:03Z")

</div>

Haha, and I’m the client (or one of them) that Skyler is referring to.

To add specificity, a really good example of this are some local Catholic charity orgs that operate out of the same churches. They’re different orgs that operate different services, but they’re based out of the same physical location (both address and defined location). Our overall database is fairly small, so we can avoid errors by creating additional locations with the same physical address, but that does add extraneous data and doesn’t seem like best practice long term or for significantly larger databases.