Relationships between people.: Difference between revisions

From Endeavour Knowledge Base
No edit summary
No edit summary
Line 1: Line 1:
Family relationships and none professional relationships between people, are included in the common information model in two main ways:
Family relationships and none professional relationships between people, are included in the common information model in two main ways:


# An ontology of relationships, using relationship types and person relation subclasses, the latter being aligned with the Snomed-CT 'Person' class.
# An ontology of relationships, using relationship types and person as a 'relation' subclasses, the latter being aligned with the Snomed-CT 'Person' subclasses with additions for in-laws.
# The data model, whereby a [[https://wiki.discoverydataservice.org/index.php?title=Health_data_model_content#Related_Person related person]] is linked to another person via a relationship type and relation entity, the latter being aligned with the above
# The data model, whereby a [[https://wiki.discoverydataservice.org/index.php?title=Health_data_model_content#Related_Person related person]] is linked to another person transitively via a relationship type and relation entity, the latter being aligned with the above.


As with the common information model in general, the two are related to each other so an enquirer can build sophisticated relationship queries and advanced family trees.
As with the common information model in general, the two are related to each other so an enquirer can build sophisticated relationship queries and advanced family trees. Most people would struggle with understanding who their third cousins were, yet they are genetically quite close.


Relationships appear complex because of the way the terms are used in plain language  
Relationships appear complex to model because of the ambiguous way the terms are used in plain language.


For example a "mother" is a type of person who is a mother of somebody. A son "has a mother" who is a mother. However, the same person who is a mother may also be a "sister" (whether or not the relationship to her sister has been authored. Consequently, there is a need not only to model the relationship between people (using a sub property of "related to"), but also to model the relation as a role independently of the relationship itself.
For example a "mother" is a person who is a mother of somebody. A son "has a mother" who is a mother. However, the same person who is a mother may also be a "sister" (whether or not the relationship to her sister has been authored). Consequently, there is a need not only to model the relationship between people (using a sub property of "related to"), but also to model the relation as a role independently of the relationship itself. The introduction of the role entity along the path of the relationship resolves the difficulty.


In addition a related person may or may not be a patient or person recorded in the record store. It may be someone unknown or abroad and there may be little information on them other than a contact detail. Therefore the related person also has to be modelled as an entity. This can be illustrated as follows:[[File:Related person.jpg|center|thumb|600x400px]]
An additional complication is that a related person may or may not be a patient or person recorded in the record store. It may be someone unknown or abroad and there may be little information on them other than a contact detail. Therefore the related person also has to be modelled as an entity separately from patients.   These classes and properties can be illustrated as follows:[[File:Related person.jpg|center|thumb|600x400px]]
Thus there are 4 potential entity types in a relationship
Thus there are 4 potential entity types in a relationship


a) The source patient (the person who has the relationship)
a) The source patient (the person who has the relationship with someone else)


b) The person who is the relation, acting in that role
b) The role of person who is the relation e.g. Mother, Carer, Sister.


c) Information about that person, which would be the same, whatever relation they were to other people
c) Information about that person, which would be the same, whatever relation they were to other people.


d) Another patient in the record store i.e. a full link between one person and another.
d) Another patient in the record store i.e. where the person is also a patient.


It is possible to model all links between people as relationships of this kind. However, in practice most relationships can be more direct e.g. the subject of an observation being a patient, or an encounter being performed by a doctor. In the common model these are modelled directly. Relationships of the kind modelled above are reserved for family relationships or non professional relationships such as carers.
It is possible to model all links between people as relationships of this kind. However, in practice most relationships can be more direct e.g. the subject of an observation being a patient, or an encounter being performed by a doctor. In the common model these more obvious ones are modelled as direct relationships. Relationships of the kind modelled above are reserved for family relationships or non professional relationships such as carers.

Revision as of 17:46, 19 May 2020

Family relationships and none professional relationships between people, are included in the common information model in two main ways:

  1. An ontology of relationships, using relationship types and person as a 'relation' subclasses, the latter being aligned with the Snomed-CT 'Person' subclasses with additions for in-laws.
  2. The data model, whereby a [related person] is linked to another person transitively via a relationship type and relation entity, the latter being aligned with the above.

As with the common information model in general, the two are related to each other so an enquirer can build sophisticated relationship queries and advanced family trees. Most people would struggle with understanding who their third cousins were, yet they are genetically quite close.

Relationships appear complex to model because of the ambiguous way the terms are used in plain language.

For example a "mother" is a person who is a mother of somebody. A son "has a mother" who is a mother. However, the same person who is a mother may also be a "sister" (whether or not the relationship to her sister has been authored). Consequently, there is a need not only to model the relationship between people (using a sub property of "related to"), but also to model the relation as a role independently of the relationship itself. The introduction of the role entity along the path of the relationship resolves the difficulty.

An additional complication is that a related person may or may not be a patient or person recorded in the record store. It may be someone unknown or abroad and there may be little information on them other than a contact detail. Therefore the related person also has to be modelled as an entity separately from patients. These classes and properties can be illustrated as follows:

Related person.jpg

Thus there are 4 potential entity types in a relationship

a) The source patient (the person who has the relationship with someone else)

b) The role of person who is the relation e.g. Mother, Carer, Sister.

c) Information about that person, which would be the same, whatever relation they were to other people.

d) Another patient in the record store i.e. where the person is also a patient.

It is possible to model all links between people as relationships of this kind. However, in practice most relationships can be more direct e.g. the subject of an observation being a patient, or an encounter being performed by a doctor. In the common model these more obvious ones are modelled as direct relationships. Relationships of the kind modelled above are reserved for family relationships or non professional relationships such as carers.