Stream: implementers
Topic: Location.managingOrganization cardinality
Luke Duncan (Aug 17 2018 at 20:32):
The IHE mCSD (mobile Care Services Discovery) profile references a number of underlying FHIR resources: Location, Organization, Practitioner, PractitionerRole and HealthcareService. mCSD’s development within IHE has been supported by the US PEPFAR programme – a $7B/year programme supporting HIV prevention, care, and treatment in 58 low and middle income countries. mCSD is a FHIR-based profile intended to be functionally equivalent to the existing IHE CSD profile. The profile’s use cases rely on a defined relationship between facilities, the services provided at these facilities, the care providers who deliver these services, and the organizational relationships under which these activities are conducted.
This last point is important. A facility may be “governed” under multiple organizational hierarchies. It is located, for example, within a Ministry of Health hierarchy regarding management and reporting. There may also be a separate hierarchy for donor-reporting… and another one, again, describing the vaccine supply chain… and so on. The 0..* cardinality is supported in the CSD profile’s XML-based schema, but this cardinality is not natively supported between the Location and Organization FHIR resources.
We have important use cases (in, at a minimum, 58 countries!) that rely on this 0..* cardinality. We would like to formally propose that the cardinality of managingOrganization in the Location resource be changed from 0..1 to 0..*.
Lloyd McKenzie (Aug 17 2018 at 20:50):
Feel free to submit a change proposal (use the "propose a change" link at the bottom of any page of the FHIR spec.) That said, it's not clear that these are all equivalent types of "management". I think you might want distinct relationships for different types of organizational relationships - or at least to qualify them somehow.
Derek Ritz (Aug 18 2018 at 18:23):
Lloyd, you make a good point about the quite different organization hierarchies. In the mCSD specification, the Organization.type is profiled as a mandatory element and it is anticipated that this would be leveraged to indicate what kind of org hierarchy is being referenced.
Lloyd McKenzie (Aug 18 2018 at 20:36):
The type of an organization and the organization's relationship to a location are different things...
Derek Ritz (Aug 21 2018 at 13:54):
Lloyd -- please can you give an example of how these things might be different?
My sense is that a location's relationship with a supply chain org hierarchy (indicated by a supply chain organization type) would indicate the location's commodity-replenishment relationship. A relationship with a healthcare delivery network's administrative org hierarchy (indicated by a healthcare administration organization type) would indicate location's administrative/reporting relationship.
I appreciate that these are implied relationships -- but it seems a useful simplification to be able to say that an org hierarchy's type indicates its purpose and the location-to-org-hierarchy relationship indicates the relationship for that purpose. I'm sorry if I'm missing something obvious, and live in fear that I'm the one who is simple, here!
Lloyd McKenzie (Aug 23 2018 at 16:12):
A government agency might be a regulator and might also serve as a distributor and might also be the organization that is the "report to" for certain types of activities. The organization is the legal entity and the Organization.code describes the type of legal entity and their primary purpose. It doesn't define all of the functions they perform or for whom. If you take the design approach of Organization.type defines function, then you'll end up with multiple copies of the same organization - one per function. I don't think that's the intended use of the resource. @Brian Postlethwaite ?
Derek Ritz (Apr 03 2020 at 16:53):
As my entry into the slowest-response-to-a-comment contest, I'd like to re-activate this conversation from almost 2 years ago. :innocent:
@Lloyd McKenzie -- could we not expect that a government agency (which would have a top-level org ID) would or could have different sub-directorates that are focused on different aspects of its operations? The sub-directorate focused on supply chain could have one org hierarchy defined by where its distribution centres are located... and another one focused on public health reporting could have its org hierarchy defined by where its regional public health offices are located... and so on. Separately, a donor who is funding a set of facilities in a country would want to be able to establish the reporting hierarchy for these facilities.
A single location would want to be able to indicate that it is a member of each of these different org hierarchies. I'm hoping that a change in the cardinality between Location and org hierarchy could allow this to be natively supported. @Luke Duncan @John Moehrke
Lloyd McKenzie (Apr 03 2020 at 17:09):
Sure, an organization could have sub-divisions/departments/whatever (sub-organizations) that have defined areas of responsibilities. That's every distinct function mandates a distinct organization. The linkage between location and organization is "what is the body that has official responsibility for this physical place". If there are multiple departments that are involved in that physical place, then the overall responsibility would rest with the parent organization. (Also look at HealthCareService - it may correspond to what you're looking for.)
Derek Ritz (Apr 03 2020 at 17:23):
So... I'm getting a sense that this is the wrong tree to be barking up. I guess I'll just put it this way. There doesn't seem to be any element in the Location data model that works well at answering the question: what are the multiple org hierarchies that this location is a member of? Since every care delivery site is a member of multiple org hierarchies, I wonder if it might be a worthwhile candidate for a new element? :slight_smile:
Lloyd McKenzie (Apr 03 2020 at 17:25):
Potentially. We'd need to understand what the objective of the link would be. Perhaps a concrete example?
Derek Ritz (Apr 03 2020 at 17:32):
An MOH facility provides services and reports indicators on a monthly basis thru an MOH reporting hierarchy. The same facility also provides donor-funded services and reports indicators on a monthly basis thru a separate donor reporting hierarchy. The vaccines store in the facility is replenished on a weekly basis from its "designated" distribution centre -- which is part of a supply chain org hierarchy. The guideline for antenatal care visits at the facility is triggered by the fact that the facility is in a region designated by the public health authority as being "high anemia prevalence"... and the public health department maintains a number of such org hierarchies for a number of disease or condition prevalences.
Ideally -- it will be easy to find out, for this facility, the list of org hierarchies that it is a member of. Some of these will be used to inform the monthly reporting... some will be used to inform supply chain activities... and some will be used to inform guideline-adherent care practices. :slight_smile: :+1:
Lloyd McKenzie (Apr 03 2020 at 18:38):
I don't necessarily see those as functions of the 'physical place' (the building, the floor, the room - which is what Location represents). Rather it seems like relationships between organizations - which is covered by the OrganizationAffiliation resource.
Lloyd McKenzie (Apr 03 2020 at 18:38):
@Brian Postlethwaite
Derek Ritz (Apr 03 2020 at 18:41):
Lloyd, they are very much attributes related to the facility... to the place.
Lloyd McKenzie (Apr 03 2020 at 18:44):
There's typically an Organization that is 1..1 with the place. You don't deliver vaccines to a building, you deliver them to the organization that's running that location. Physical places never create reports - people do.
Lloyd McKenzie (Apr 03 2020 at 18:45):
If you're talking about active participation or responsibility, you're always talking about Organization, not Location
Derek Ritz (Apr 03 2020 at 18:49):
So... if the MOH is operating 1000 facilities... are you thinking there's a different organization ID for each of them... because there's a different supply chain relationship for each of them, for sure. Sorry if I'm missing some nuance here, Lloyd... but when you say there's a 1..1 relationship between a location and an organization... do you think it can only mean w.r.t. "payroll"? A location will be part of lots of org hierarchies... and examples of these are already enumerated.
Lloyd McKenzie (Apr 03 2020 at 19:18):
Yes. Each facility would have an organization that represents the group of people (and authority to make decisions) that is associated with that site. You would also have sub-organizations for each department. The 'location' is just the physical space where the organization has authority.
Lloyd McKenzie (Apr 03 2020 at 19:19):
(Think of location like building/floor/room/bed - they are places only)
Derek Ritz (Apr 03 2020 at 19:38):
I'm struggling, Lloyd. I can't tell whether you don't understand me... or whether you don't think these are valid use cases... or whether you think these use cases are already well-addressed... or what. There is obviously a recognition that there needs to be a relationship between locations and org hierarchies... there is an element in the Location resource to establish one of those. My point is that there are multiple org hierarchies... and you don't seem to disagree with that. I guess what I can't seem to get my head around is that you are advocating for one (and only one) of the multiple org hierarchies to be represented in the relationship. As far as I can tell, it is the org hierarchy relationship related to "payroll" that seems to be the one most focused on. Why is that? And what is the danger that you foresee in moving to a 0..* relationship?
Lloyd McKenzie (Apr 03 2020 at 19:42):
I think the use-cases are well handled - and they're handled on the organization side, not the location side. The link on location is "what's the organization that is responsible for this physical site". For something like a hospital or clinic, that will typically be a 1..1 organization. I.e. it would never be the MOH for the hospital, it would always be a hospital-specific organization. The hierarchical links you're interested in would be handled by organization affiliations.
Derek Ritz (Apr 03 2020 at 19:45):
I'm thinking of facilities in rural Tanzania, too... not just hospitals in downtown Toronto. Are you sure you understand my use cases?
Lloyd McKenzie (Apr 03 2020 at 19:47):
Don't care about the where. A facility in rural Tanzania would still have an 'organization' that represents the group of people there who can make decisions and take responsibility. The Location represents the physical building - even if it just happens to be a temporary tent.
Grahame Grieve (Apr 03 2020 at 19:50):
@Derek Ritz I haven't followed all this discussion but it seems to me that HealthcareService is at least part of your answer. It's common for a single location to provide multiple services that have different managing Orgs
Vassil Peytchev (Apr 03 2020 at 19:50):
I think part of the confusion might be that when organizations talk about locations, e.g. a car dealership has three locations in an area, they are talking about business units. It seems to me that if you replace the word "location" with a "sub-org", and also disregard the current very limited apparent scope of the OrganizationAffilitaion resource, you can successfully express what you need.
Jean Duteau (Apr 03 2020 at 19:51):
Yes, our "Location" resource is should be renamed to "PhysicalSpace" because the word confuses people.
Derek Ritz (Apr 03 2020 at 20:02):
So... a physical space operates under the auspices of a managing organization and, on a monthly basis it sends monthly reports based on its position in the managing organization's org hierarchy. Some of its services are funded by a donor. On a monthly basis it reports to that donor... based on a different org hierarchy. The vaccines that are delivered to this physical space come from its designated replenishment centre... which is part of a supply chain org hierarchy. And this particular physical space is in an area that is part of a public health org hierarchy related to anemia prevalence, and so antenatal care services provided in this physical space take that into account when providing guideline-adherent care.
This physical space has these org hierarchy relationships. A different physical space... also operating under the same managing organization... has a different set of org hierarchy relationships. I'm looking for a parsimonious way to reflect these relationships... and it seems that a 0..* cardinality in the location to org hierarchy relationship would do that.
Jean Duteau (Apr 03 2020 at 20:04):
no, i'd go the other way and link from the organization(s) to this location. Then you can just search for organizations that point to this location. I never felt that managingOrganization should be on the Location resource because it confuses the relationship to me.
Grahame Grieve (Apr 03 2020 at 20:04):
I think you'd also want to indicate what type of relationship, not just a 0..* relationship.
Derek Ritz (Apr 03 2020 at 20:04):
This example, btw, is not from Toronto. This is a common situation in rural Tanzania... and it informed the work done on the IHE Care Services Discover (CSD) specification. CSD models the relationship between places, organizational hierarchies, health workers, and health services. IHE developed mCSD to try to model this same set of relationships in FHIR... and we were able to come pretty close.
Jean Duteau (Apr 03 2020 at 20:05):
Grahame Grieve said:
I think you'd also want to indicate what type of relationship, not just a 0..* relationship.
Which is easily handled by the OrganizationAffiliation resource
Derek Ritz (Apr 03 2020 at 20:12):
So... and sorry if I'm being stoopid... how would I get a list of all the org hierarchies that a location is part of? If I start at Organization... exactly which search parameter would I use? How would I "walk the tree" (since these are org hierarchies, after all)?
Jean Duteau (Apr 03 2020 at 20:25):
Well, you are going to use a combination of HealthcareService and OrganizationAffiliation resources to present the hierarchy and the delivery of service, so depending on what question you are specifically asking, you would use Organization?_has:OrganizationAffiliation:primary-organization:location=[reference] or Organization?_has:HealthcareService:organization:location=[reference]
Jean Duteau (Apr 03 2020 at 20:27):
those are obviously just examples. It really depends on exactly how you model the hierarchy using OrgAffiliation and the delivery of services using HealthcareService.
Derek Ritz (Apr 03 2020 at 20:31):
Thanks, Jean. I'm going to have to learn more about how this resource is expected to work. It seems (on original gut instinct reaction) that OrganizationAffiliation, if used in this way, will be a permutation of org, location, and service. And for any org reference... there may be a need to "walk the tree" to navigate the partOf relationships up or down (depending on the use case).
I'll spend some time with it... and will try not to be too much a sissy about how daunting it looks...
Grahame Grieve (Apr 03 2020 at 20:38):
your problem sounds daunting
Peter Jordan (Apr 03 2020 at 20:42):
Jean Duteau said:
no, i'd go the other way and link from the organization(s) to this location. Then you can just search for organizations that point to this location. I never felt that managingOrganization should be on the Location resource because it confuses the relationship to me.
I'm not so sure. Certainly, the provider directory services available here in NZ (both FHIR and non-FHIR) are modeled on the healthcare services available at a facility (location) that is managed by an organisation. This is published each month by our Ministry of Health and the format of the extract renders well to the current FHIR Model whereby Organization resources are referenced by the HealthcareService and Location resources.
Organization details are a secondary concern for most consumers and providers, here. They're mainly of interest for contractual and funding purposes and what you're proposing looks more akin to typical business CRM-type model which, I guess, might suit some countries.
Jean Duteau (Apr 03 2020 at 20:43):
Sure, but HealthcareService has a link to the Location and the Organization involved with that service.
Peter Jordan (Apr 03 2020 at 20:54):
Yes, if HealthcareService is used then I would place the reference to Organization there, rather than the Location Resource. However, I still wouldn't place a Reference to Location in Organization as that would create circular references.
Derek Ritz (Apr 03 2020 at 21:55):
There are also org hierarchy relationships that don't map directly (or even well) to healthcare services. The supply chain org hierarchy... or the indicator reporting org hierarchy... or the clinical decision support org hierarchy (e.g. the location being in a "high anemia prevalence" area that impacts ANC guidelines). For all of these... it is useful to be able to start at the Location and say: "what org hierarchies apply here?".
Lloyd McKenzie (Apr 03 2020 at 23:59):
Right - but you're not actually starting at the 'building made of wood & concrete', you're starting at the group of people who do stuff/manage stuff at that building. So you're starting with Organization, not Location.
Derek Ritz (Apr 04 2020 at 00:57):
I want to learn! :slight_smile: Let's start at the Organization. Lloyd... the organization is the Tanzanian Ministry of Health. How do I get from there to the donor reporting hierarchy for monthly PEPFAR-funded HIV care metrics being reported from "this" facility (MOH-assigned facility ID=12345)?
Lloyd McKenzie (Apr 04 2020 at 02:36):
There will be lots of organizations. The organization tied to the location is almost certainly not going to be the Tanzanian Ministry of Health. Rather it'll be an organization that is specific to that clinic/hospital (whether it's registered as a legal entity or not is irrelevant). That organization will have a chain of responsibility that leads to the Tanzanian Ministry of Health (whether it's a direct link or through intermediaries depends on how the ministry divides responsibilities). The organization that is 1..1 with the hospital may have further have additional sub-organizations representing departments if responsibility is divided that way. The reporting hierarchy would be handled using OrganizationAffiliation. Location wouldn't likely even come into play. Imagine that you have a location that's half hospital/half school. In FHIR that's one Location - there's one physical structure. We tend to care about physical structures when we're doing geo-location stuff, but mostly we tend to just care about organizations.
Derek Ritz (Apr 04 2020 at 03:33):
Lloyd... I wasn't talking hypothetically. I was speaking in the first person about places I've been. The facility is operated under the auspices of the Tanzanian MOH. The PEPFAR reporting org hierarchy depends on the physical place where this facility is located... its long and lat. Using the IHE CSD spec we can model the facility's MOH org hierarchy and its PEPFAR org hierarchy. I need to be able to do the same using FHIR. If the cardinality of the org hierarchy relationship is altered from 0..1 to 0..* then this is easily done.
I don't understand the issue, here. If we're going to support one of the org hierarchy relationships on the Location resource... why not support all of them?
Lloyd McKenzie (Apr 04 2020 at 03:48):
I understand that it's operated under the auspices of the Tanzanian MOH. What I'm saying is that when representing that state in FHIR, you generally would NOT have the Location pointing to the MOH organization. The Location would point to a location-specific Organization. The location-specific Organization would have a 'partOf' relationship to the MOH
Lloyd McKenzie (Apr 04 2020 at 03:48):
The hierarchies would all be to the location-specific Organization, NOT to the physical building.
Last updated: Apr 12 2022 at 19:14 UTC
