SNOMED CT Editorial Advisory Group

Page tree

A question from a member country on when to use "X (person)" vs. "X of subject (person)" has exposed issues with determination of equivalence in information models that either split the relationship from the condition or uses a precoordinated Situation concept to represent the SUBJECT RELATIONSHIP CONTEXT.

A report on the use of person concepts as values for the SUBJECT RELATIONSHIP CONTEXT attribute is located at: https://docs.google.com/spreadsheets/d/1LTPSInpRC_HMPniQANM8NL86WCieSAttoPYDS_yxjno/edit#gid=1

"X of subject" concepts were introduced and primarily used as values for SUBJECT RELATIONSHIP CONTEXT, but are currently modeled as subtypes X (person). Is Person the correct hierarchy for these to be placed?  
"X of person" was introduced to support the SUBJECT_RELATIONSHIP_CONTEXT of Situations.

A reference paper written in 2006 provides some historical background: https://confluence.ihtsdotools.org/download/attachments/17039782/Subject%20relationship%20context%20values_EDC_20060127.doc?api=v2

The main distinction made in the reference paper is that between an "Entity" and the "Role" played by an Entity.  However, this distinction is not made within the person hierarchy, with << 444148008 |Person in family of subject (person)| primarily representing roles that Person entities play being in the same Person hierarchy. Since the 444148008 |Person in family of subject (person)| is primarily used as values for the SUBJECT RELATIONSHIP CONTEXT attribute, we can question why it is in the Person entity hierarchy.


We are not separating roles from entities in the current hierarchies.  Because these are classes and not instances, we are constrained in how we can represent them.  This is more challenging in the current context of changing family constructions.  Father/mother and other familial relationships need to be explicit in that what is being referred to is the hereditary/genetic relationship between the patient and the subject relationship context. Need to consider the social context in this as well.  Do we need to separate out biological from social familial structures?  

In general, there is a feeling that we need to represent both the genetic and social constructs of familial relationships.  The X of subject (person) concepts were developed to support a specific attribute and should they be separated out.  

Fetus of subject is another issue. Do we need to be more specific in the definition of the SUBJECT RELATIONSHIP CONTEXT so we define explicitly what type of relationship we are trying to represent.  Is this an entity to entity relationship or an entity to role relationship?  

A related question to fetus.  

This is an issue in mental health as well that crosses over the biological and social aspects of relationships.

Questions

  • A question raised by the reference provided is whether a well-established role (e.g. father) can also exist as an entity?  
    • Can a father exist as a standalone entity without the establishment of a relationship to another entity?
  • Are familial relationships Roles or Persons?
  • Should X of subject (person) concepts be moved out from the Person hierarchy into their own "value set" to support the SUBJECT RELATIONSHIP CONTEXT attribute? 
  • How do we distinguish between the mother and the fetus in some procedures and disorders?
    • How do we handle "Fetus of subject" given the sensitivity of some members of having a (person) semantic tag? 
  • No labels

1 Comment

  1. Jim Case

    From Monique van Berkum 

    Feedback on “X (person) vs. X of subject (person)” after the April 5,2022 EAG meeting:

     To avoid the issue of whether these are people vs roles, consider replacing |Subject relationship context| with an attribute like |Person related to the subject|.

    1. With respect to whether these Situation concepts are only needed for genetic disorders:

    Agree that we should not assume that situation concepts about related persons will be restricted to exclusively capturing information about persons with a genetic/blood relationship to the subject.

    Examples:

    • <X> cancer in mother (meaning <X> cancer in mother of subject) - In a patient record, this may indicate:
      • A genetic risk of cancer for the subject (if the mother is biological)
      • An environmental risk of cancer for the subject (whether the mother is biological or non-biological)
    • 438618001 |Mother does not smoke (situation)| - This is not about genetics. It is about risk of exposure.
    1. I would avoid creating “biologic” and “non-biologic” versions of each related person and instead consider representing “biologic” and “non-biologic” with another attribute (perhaps subtyping the person related to subject attribute as Jeremy suggested).
    • Attribute: Biologic relationship to subject

    Values:

      • Biological
      • Non-biological
    1. With respect to the discussion around gender fluidity and possibly renaming persons like “Mother”, “Father” with more explicit terms, etc.:
    • I think we need generic terms like “Mother” (with text definitions of what that means).
    • While the gender of a person may be fluid, we have to be able to have “generic” terms that represent a person at a given point in time. Although an individual may change how they define themselves over time, we can only document what we know to be true at the time of documentation.
    1. Given changing family roles, the 2 concepts that refer to “both parents” (|Both parents smoke (situation)| and |Both parents misuse drugs (situation)|) need review:
    • The person hierarchy is true:
    • However, the situation modeling and inferred parents are not necessarily true. We can no longer assume that “both parents” means a Father and a Mother:
    • I would consider replacing theses codes with new ones (e.g., Mother and father smoke). However, “Both mothers smoke” or “Both fathers smoke” won’t work because they would have two identical role groups. Therefore, perhaps retiring these would be best.
    1. Fetus
      • In the interest of not getting bogged down on this issue, I would separate it completely from the rest of this for now and address it later.