I’d like to propose adding a new core entity to OpenMRS: Organization.
Currently, Location is used to model physical spaces like wards and departments. However, there’s no built-in way to represent the hospital or institution itself—the entity that owns or manages those locations.
Why this matters:
In setups like ICRC, we often manage multiple hospitals, each with its own set of locations. Without a clear way to represent the hospital level, we end up overloading the Location model, which introduces ambiguity and makes configurations harder to manage and scale.
The idea is to support multi-hospital (multi-organization) setups in a more structured and maintainable way. This would allow for clearer separation of data and better resource and patient management across different hospitals.
To @dkayiwa point, this is already pretty well-established using Location Hierarchies and Location Tags, at least in the PIH implementations and core modules that I have worked on.
The general model is that a facility is modeled as a Location and is tagged as a “Visit Location”, and then individual departments are modeled as locations whose parent is set as that Visit Location, and these departments are tagged as “Login Location”, as well as any other specific location tags as may be useful to control what functionality is enabled.
The result is that Visits are created and associated with the top-level Visit location, and Encounters are created and associated with the lower-level Login Locations.
For implementations that choose not to have this distinction (eg. everyone just uses the facility location for everything), then that is also supportable by having the top-level location tagged as both a “Visit Location” and a “Login Location”, and not having any child locations associated with it.
This model has been working well, and I would be very reluctant to add a new Organization type unless it offered significant value add in some way.
Given how extensively the Location construct is used throughout OpenMRS, and given the ability to have Locations with different attributes, tags, and hierarchies, my sense is that we should try to continue to evolve Location to meet these needs rather than create a separate, parallel object that modules and the rest of the OpenMRS ecosystem needs to learn how to use, and adapt to for supporting both older and newer versions of OpenMRS core.
I concur with @dkayiwa and @mseaton that we don’t necessarily need a new core entity and we can hopefully leverage the existing Location object for this.
That said, I’d like to put in a plug for an “Organization” tag for a couple of reasons. First, I think it’s likely we need to somehow model “external” as well as “internal” organizations and we wouldn’t want to represent “external” locations as visit locations. Second, while the visit location can be used to model facilities, the functionality is actually flexible enough that a visit location can pretty much exist at any place in the hierarchy. That would allow us to support cases where, e.g., there is a single organization that runs or operates multiple facilities in a cleaner way. Third, and while not the most important, if we have a tag that semantically maps to the same concept as a FHIR Organization, we can actually leverage that in the FHIR2 module to spin out Organization resources where appropriate.
Having the “Organization” as a “Location” tag seems a lot easier to implement since we don’t need to have big development to have the OpenMRS supporting it, and can just implement small developments to add the functionalities that we need.
I mean, you’re welcome to try adding the Location tag and we can add some handling around it to FHIR2. I’m not sure it’s going to solve the problem you linked to though.
The problem there is that the concept of a “person’s location” is not a concept OpenMRS really has any idea about and there are a few different ways of representing that (an attribute as the ICRC distribution does or a patient identifier location, which is closer to the core concept).
The easiest implementation may just be to change the backend definition of the PatientResource (in the ICRC distro) to include the location as part of the display string. Unfortunately, I think the only way to do this is to replace the PatientResource1_9 with a custom verison…