Proposal: New PersonalRelationshipRoleType codes
Return to Patient_Administration
Proposal Name: New PersonalRelationshipRoleType codes
Submitted by: Wendy Huang | Revision date: March 18, 2009 |
Submitted date: March 18, 2009 | Recommendation ID: CA-200904-24 |
Vocabulary Object Change Summary
Abbrev. | Description: | # to add: | # to remove: | # to change: |
D | Concept Domains | 2 | ||
S | Code Systems | |||
C | Concept Codes in a Code System | 3 | 12 | |
V | Value Set | 1 | ||
B | Context Binding | 1 |
Contents
Summary Recommendation
Add several concept domains related to PAFM content and add some new codes to personal relationship, while tweaking the hierarchy.
Issue
The AssignedRoleType and PersonalRelationshipRoleType concept domains are referenced in PAFM ballot material but don’t actually exist.
In addition, there’s a need for a “higher level” code to deal with extended family relationships that doesn’t involve fully qualifying them and a need to be able to identify son or daughter without distinguishing whether they’re natural, foster, adopted, etc.
As well, Roommate is currently captured as a family member, when there’s no familial relationship in the role or definition. Domestic Partner is another type of significant other. (If they weren’t a significant other, they wouldn’t be a domestic partner, just a roommate.)
Current State
AssignedRoleType value set description:
A role type that is used to further qualify an entity playing a role where the role class attribute is set to RoleClass AssignedEntity. The suggested values from V2.x include clinic receptionist, referral agent, staff physician, courtesy physician, resident, physician assistant, physical therapist, psychiatrist, psychologist, pharmacist, registered nurse, licensed practical nurse, licensed vocational nurse, nurse practitioner, etc.
Examples: Janitor, Chief of Staff, Referral Agent, Security Guard, ICU Runner,Visiting professor PersonalRelationshipRoleType value set description:
Types of personal relationships between two living subjects.
Example: Parent, sibling, unrelated friend, neighbor
RoleCode
FAMMEMB (Family Member) AUNT* (aunt) CHILD (Child) SONC (Son) SONADOPT (adopted son) SONFOST (foster son) SON (natural son) STPSON (stepson) DAUC (Daughter) DAUADOPT (adopted daughter) DAUFOST (foster daughter) DAU (natural daughter) STPDAU (stepdaughter) CHLDADOPT (adopted child) DAUADOPT (adopted daughter) SONADOPT (adopted son) CHLDFOST (foster child) DAUFOST (foster daughter) SONFOST (foster son) CHLDINLAW (child in-law) DAUINLAW (daughter in-law) SONINLAW (son in-law) NCHILD (natural child) DAU (natural daughter) SON (natural son) STPCHLD (step child) STPDAU (stepdaughter) STPSON (stepson) COUSN* (cousin) DOMPART (domestic partner) GGRPRN* (great grandparent) GRNDCHILD* (grandchild) GRPRN* (Grandparent) NIENEPH* (niece/nephew) PRN* (Parent) ROOM (Roomate) SIB* (Sibling) SIGOTHR (significant other) SPS (spouse) UNCLE* (uncle) FRND (unrelated friend) NBOR (neighbor)
- Note: Some children have been excluded from the hierarchy because they’re not relevant to the current proposal.
Rationale
See Issue
Recommendation Details
1. Create a concept domain called AssignedRoleType under RoleCode with the definition currently found in the AssignedRoleType value set. Delete the AssignedRoleType value set. (The set of codes in the value set are not representative and do not provide even reasonable example coverage of the breadth of the concept domain.)
2. Create a concept domain called PersonalRelationshipRoleType under RoleCode with the definition currently found in the PersonalRelationshipRoleType value set. Create a representative binding from the new concept domain to the existing value set.
3. Modify the ActRole table as follows:
ActRole
FAMMEMB (Family Member)AUNT* (aunt)CHILD (Child) SONC (Son) SONADOPT (adopted son) SONFOST (foster son) SON (natural son) STPSON (stepson) DAUC (Daughter) DAUADOPT (adopted daughter) DAUFOST (foster daughter) DAU (natural daughter) STPDAU (stepdaughter) CHLDADOPT (adopted child) DAUADOPT (adopted daughter) SONADOPT (adopted son) CHLDFOST (foster child) DAUFOST (foster daughter) SONFOST (foster son) CHLDINLAW (child in-law) DAUINLAW (daughter in-law) SONINLAW (son in-law) NCHILD (natural child) DAU (natural daughter) SON (natural son) STPCHLD (step child) STPDAU (stepdaughter) STPSON (stepson) EXT (extended family member) AUNT* (aunt)DOMPART (domestic partner)COUSN* (cousin) GGRPRN* (great grandparent) GRNDCHILD* (grandchild) GRPRN* (Grandparent) NIENEPH* (niece/nephew) UNCLE* (uncle) PRN* (Parent)ROOM (Roommate)SIB* (Sibling) SIGOTHR (significant other) DOMPART (domestic partner) SPS (spouse) FRND (unrelated friend) NBOR (neighbor) ROOM (Roommate)
- Note: Some children have been excluded from the hierarchy because they’re not relevant to the current proposal. Relationships with descendant codes not shown remain unchanged by this proposal.
Descriptions:
SONC: The player of the role is a male child (of any type) of scoping entity (parent)
DAUC: The player of the role is a female child (of any type) of scoping entity (parent)
EXT: A family member not having an immediate genetic or legal relationship e.g. Aunt, cousin, great grandparent, grandchild, grandparent, niece, nephew or uncle.
This code system is used in the attribute is PersonalRelationship.code within the PersonalRelationship Role Class (Client Registry models).
Discussion
If we wanted to, we could group CHILD, PRN, SIB and SIGOTHR under a concept of “Immediate Family”. We don’t have a use-case for that code, but have no problem amending the proposal to introduce the concept.
The PersonalRelationshipRoleType value set needs to be cleaned up and is not included in the scope of this current proposal.
Recommended Action Items
MnM to implement recommendation