Jim Case

This meeting is being recorded to ensure that important discussion points are not missed in the minutes.  The recording will be available to the SNOMED International community.  Joining the meeting by accepting the Zoom prompt declares that you have no objection to your comments being recorded

Jim Case

None noted.

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 vs. using a precoordinated Situation concept to represent the SUBJECT RELATIONSHIP CONTEXT.

3/15/2022 - Update

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

• Are familial relationships Roles or Persons?
• Given "X of subject" is primarily used as the value for this attribute, should these concepts be moved out from the Person hierarchy into their own "value set"? 
• Is Person the correct hierarchy for these to be placed?  
• How do we handle "Fetus of subject" given the sensitivity of some members of having a (person) semantic tag? This is needed when procedures or conditions are performed/recorded in a fetal record as opposed to a maternal record.

Discussion:"

Previous discussion has been moved to Confluence discussion page at: X (Person) and X of subject (person" was introduced to support the SUBJECT_RELATIONSHIP_CONTEXT of Situations.  Monique van Berkumwill look for some history on why they were added. Suggested that the ECE might have some history on these.  Question is whether we need to separate out the relationship values from "persons" as a class?

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.

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?

4/5/2022

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 RELAITONSHIP 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.  How do we distinguish between the mather and the fetus in some procedures and disorders.

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

Decision:

Background will be investigated.  The person hierarchy needs some review and rationalization.

Background document posted above.  Will review for next meeting.

Discussion:

)

• • Changing roles in family structure requires a distinction between biological relationships and non-biological familial relationships.
  • Existing "Person" hierarchy is in need of review and updating.
  • Suggestion has been made by multiple people to handle this issue through reorganization of the values for "subject relationship context" (separate hierarchy?)
    • "Role" hierarchy exists.  Values imply a relationship to a physical entity (e.g. 766941000 |Therapeutic role (role)| implies a substance or product)
  • Also has been suggested to create new attributes that allow for more specificity
  • Need to consider that subtypes of "Person" are also used as values for the FINDING INFORMER attribute. 
  • The reference paper provides two mechanisms to represent "fetus"
    • Creation of a robust fetal anatomy hierarchy
    • Use of a SUBJECT RELATIONSHIP CONTEXT value (provided subject relationship context values were moved out of the person hierarchy)

A question was raised as to whether we need the "X of subject (person)" at all since the relation itself defines the relationship.  These concepts originated around 2009, but only a few were present at that time.  It may have originated due to the need to represent the "Fetus of subject".  Suggested that we separate out the difficulties of fetal disorders and findings from the rest of the subject relationships.  

This also raises the question about the degree of pre-coordination there should be in the International release?  

The distinction between X (person) and X of subject (person) is lost when looked at in the context of a medical record.  The element within the record in which a term is used provides the context in most cases.  The most compelling reason to keep the X of subject is related to fetal disorders and procedures, which is something that has been agreed is a separate issue.  (i.e. representing "father of fetus" as opposed to "father of the subject of record")   

The FINDING INFORMER attribute is problematic and needs a comprehensive review for its usefulness.

There are also issues with the relative non-specificity of FSNs in the Situation with explicit hierarchy with regards to the subject relationship.

It is reasonable to assume that the underlying reason for the addition of the X of subject concepts is no longer relevant. 

Decision:

Test the impact of replacing "X of subject" values from the situation concepts.  Inactivate the "X of subject (person)" if no adverse effects.

Review the existing person hierarchy for quality.  Future considerations will be around roles, gender identity and sexual orientation related to person. 

•  Jim Case to implement changes to the Situation concepts Jim Caseto reword definition and send out to EAG for review.

Discussion:

It is agreed that the replacement of FSNs is less destructive than inactivation and replacement of concepts.  This is only relevant where current content is modeled with above and below reference range.  Concepts that are inherently ambiguous are still used in clinical recording.  Adding forced meaning to these might make them less useful.  Suggested to identify these concepts using a refset that they are problematic from an interpretation point of view. 

This project was an effort to reduce the ambiguity of existing concepts to ensure clarity of meaning.  Retention of ambiguous content may provide clinical recording simplicity but may be in conflict with precision.  There is a conflict between the utterances used in clinical recording and the desire to provide structured analytical data.  The issue may be exposed when looking at new technologies that go from speech to text to coding...

Suggested that the ambiguity can be resolved by using other "imprecise" terms such as "increased" for "above reference range" and "increasing" for "increased relative to prior measurement". Alternative description types may assist in representing broader or ambiguous descriptions.  Another suggestion is to allow for these imprecise concepts, but mark them as such within the terminology.

Topic not completed.  Carried over to next meeting.

TBD