Stream: implementers
Topic: Location Resource
John O'Gorman (Mar 20 2017 at 14:49):
Newbie alert. My FHIR-Speak may not be very precise, so bear with me.. I have some questions / comments about Resource Location aspect of the spec, so my first question is: Am I in the right place?
John Moehrke (Mar 20 2017 at 15:11):
John, you might be in the right place... might not... If your question is about implementing the FHIR specification, yes. If it is about an existing tool, like HAPI, there likely is a dedicated stream to that tool. But, go ahead and ask... we don't hurt anyone on their first few questions.
John O'Gorman (Mar 20 2017 at 15:21):
Thanks John... It's a classification question more than anything. Here goes - and apologies for the length:
Resource Location
5.15.2 Boundaries and Relationships
"Locations and Organizations are very closely related resources and can often be mixed/matched/confused."
No, it seems to be Location and Physical Assets that are confused here...
"The Location is intended to describe the more physical structures managed/operated by an organization, whereas the Organization is intended to represent the more conceptual hierarchies, such as a ward."
Why not just call them Physical Structures?
A specific ward is-part of a given Physical Structure... this modelling almost guarantees maps and floor plans could not be derived from or used used by it.
"A Location is valid without an address in cases where it could be purely described by a geo-coded location in remote areas, or when recorded by a device."
Agreed.
Locations with a mode = "kind" would also likely not have an address, as they are just a type of location, but could also have an address where they can be found at the address.
???
"Another use of location could be for describing a Jurisdiction. This jurisdiction may be considered a classified boundary which could be a combination of a physical boundary, and some other discriminator(s):
Nation - Country wide community or Federal Government (Ministry of Health)
Province or State (community or Government)
Business (throughout an enterprise)
Business scope (CDC/FDA)
Business segment (UK Pharmacy)"
These uses seem to be confusing Place (e.g. US) and Organization (e.g. FDA) on top of Physical Asset (Atlanta Children's Hospital) and - in the Example section -- things like roads and ambulances. Why, when the objective is interoperability (with other standards, for example) would 'Location" be modeled this way?
Lloyd McKenzie (Mar 20 2017 at 15:42):
A Location can also be "side of the road" or "2 mile radius around point X". So it's a mixture of the geographical location and the physical infrastructure at that location.
John O'Gorman (Mar 20 2017 at 16:04):
I get that it's a combination of (at least) Things and Location, but why? Why not have a separate category for Facility, or Infrastructure. And why put 'Jurisdiction' - which seems to be a combination of Location and Organization into the mix?
Lloyd McKenzie (Mar 20 2017 at 16:27):
Jurisdiction might not have been the best term to use. The focus is on the borders - Jurisdiction would be a location of interest in public health and similar purposes. Not sure what you mean by "separate category"
John O'Gorman (Mar 20 2017 at 16:42):
"Not sure what you mean by "separate category""
Sorry - Resource.
Lloyd McKenzie (Mar 20 2017 at 17:02):
We have a resource for the legal entity that has responsibility (Organization), one for the physical site (Location), one for the capacity to perform (HealthcareService) one for the available equipment (Device) and one for the personnel (Practitioner). What additional resource(s) do we need?
John O'Gorman (Mar 20 2017 at 17:09):
I'm going to assume yours is a rhetorical question, Lloyd,
Just an opinion, but I think separating Physical Things from their Location ( and their Function) is a much tidier way to model it. Thanks for your responses.
Lloyd McKenzie (Mar 20 2017 at 17:31):
Hi John, it's not so much a question of "tidy modeling" as it is "what sorts of tables to most systems have in their data base"? We only create distinct resources when we're confident that the division is something most systems will have an easy time managing, when it refects how systems think of and access data and that each concept is generally distinctly identifiable and has its own state. Modeling elegance tends to rate much further down the priority scale than it did in v3.
John O'Gorman (Mar 20 2017 at 17:55):
Hi Lloyd. Agree that there should be less of a priority on pretty models than practicality, but maybe there's a slight disconnect between how 'systems think of and access data' and the way humans - especially lay folks like myself - identify, classify and associate those concepts independent of electronic systems.
I am using a model called Q6 that uses universal classes (see article here: https://www.linkedin.com/pulse/finding-universals-enterprise-information-management-john-o-gorman ) that treats all medical terminology and entities as identifiable resources. The idea is to get any medically-related terminology working with any other potentially overlapping data set using common classification and identity protocols.
A final apology for the self-promotion, but I am keenly interested in initiatives like FHIR - especially if they can reduce the amount of time practitioners spend entering - and re-entering data.
Thanks again for your responses. Much appreciated!
Sandeep Giri (May 23 2017 at 19:09):
We are using Location to represent a single clinic. Any suggestions on what values to use as Location.identifier?
Ideally this should be a value that external applications can also know (as opposed to using internal department ID's). An example use case is to serve a query that allows an external applications to search for all available appointment slots at a specific clinic, where something like "GET Slot?Location=<location identifier&status=free>" will be great to offer.
One option is to use the name of the clinic itself as the identifier, as long as you avoid users having to type in the clinic name with smart drop-downs -- but I just wanted to check if anyone else has run into similar issues, and how you addressed it. Thanks
Lloyd McKenzie (May 23 2017 at 19:21):
Only use the identifier element if you actually have an identifier. It's straight-forward to search by name or other elements if there isn't an actual identifier.
Sandeep Giri (May 23 2017 at 21:16):
thanks @Lloyd McKenzie - in this case, the user wants to search for open appointments at a specific clinic, hence the need to uniquely identify the clinic. Since clinics don't necessarily have unique names, this may need to be a combination of name and address. But I hear your point, and translate it as -- use name and address as 2 separate required search parameters to uniquely identify a clinic, rather than forcing applications to use an identifier that concatenates name and address
Lloyd McKenzie (May 23 2017 at 21:22):
If you're using REST, you'll have a resource id for the clinic. That should be sufficient for unique identification.
Sandeep Giri (May 23 2017 at 21:47):
yes, but the application that's trying to get open slots at a given clinic may not know the FHIR resource id for the Location resource representing the clinic -- so, they will have to call "GET Location?name=X&address=Y", get resource id for Location, and then call "GET Slot?location=<location resource id>".. I was trying to see if the applications could search with a single API call using commonly known references (such as names and address) to identify the clinic. I guess getting a resource id for Location first is not that bad either, perhaps cleaner. Thanks.
Lloyd McKenzie (May 23 2017 at 22:12):
Well, you can use chaining - GET Slot?location.name=X&location.address=Y - if the server supports that.
Last updated: Apr 12 2022 at 19:14 UTC
