Demographic package use ACTORs & ROLEs but there is nothing that can capture the concept of a UNIT (resource) like buildings, departments, rooms, beds, etc. This is used for to capture patient admissions information (location) but it could be also be used to capture physical resources used, linked or referred by ACTORs or COMPOSITIONs.
Suggestion is to name this UNIT, extends from PARTY.
I don't agree that an ACTOR would have a contractual relationship with a PLACE - an ACTOR can just be in a PLACE, and that is his/her location for some time. A PLACE isn't an active Party, it's a passive entity. Again, I think we need to follow the ontological semantics here - the relationships are clearly different in that sense. Consider if you ran a query looking for all current relationships of a PERSON xyx, you would not expect to get back also connections to physical places, like their physical office or department building, only organisational / personal relationships.
In any case, I'm not sure that representing Actor current location inside the demographic system is a good idea, since this is likely to be very volatile information.
Also if PLACE is modelled as an ACTOR subtype, it's going to be confusing distinguishing between the ORGANISATION that a PERSON is admitted to, and the physical Location at the organisation site where they will stay (some PLACE, e.g. Ward 2, Building B).
Thomas, running a query like that is not really a problem, just filter out based on relationship type.
I also see no reason for confusion, as you said a PLACE is a passive entity. Very often what is more important than whether or not somebody is admitted to an ORGANISATION is where is he/she physically located, or what physical (passive) resource does he/she consumes.
By volatile information do you refer to the burden having versioning/audit?
But fine, I see you see these differently - so, what is your conclusion for now? What should be done on this issue?
concretely that will work, but only if you know you have to do it; it's something that would be completely unexpected because Party-Party relationships don't normally include 'relationships' to passive objects or physical places, in organisational theory.
I completely agree that the information is important, I just think we should model it in a clear way. I have not yet tried to build a model proposal in UML, but I would suggest that PLACE (or whatever we want to call it) is a top level object type, like PARTY. PLACE would be able to contain PLACEs (not the same instances, obviously), and a PLACE would have various identifying information and other details ('purpose' for example).
BTW: in ontologies like BFO, there is quite a developed notion of 'Site', which is more or less a 'Place' as we are describing here, and which occupies a 'spatial region'. I'll look into the correct relationships between sites and sub-sites.
PARTY would have some generic optional relationships with PLACE, e.g. 'owns', 'uses' etc - we would need to think these through.
ORGANISATION, and sub-Organisation units would have more specific optional relationships with PLACE, e.g. 'facilities'.
PERSON would probably have some special relationships as well, including to represent 'being at' during a certain period of time.
I have some good modelling publications that address some of this - when I get a moment, I'll provide some pictures of possible models.
Have you looked into the CONSTYS definitions related to this topic?
PLACE seems to be something like Point of Care ; https://contsys.org/concept/point_of_care
RESOURCE is another important entity when doing resource planning to execute healthcare services: https://contsys.org/concept/resource
For our Surgery module we created an Archetype to model healthcare resources: https://github.com/bjornna/dips-ckm/blob/nymaster/archetypes/cluster/openEHR-EHR-CLUSTER.healthcare_resource_dips.v1.adl (I should have it translated)