MnM Minutes CC 20070209

February 9, 2007

Attendees

• Lloyd
• Woody
• Craig
• Austin
• Lee
• Christy
• Mead
• Patrick
• Gregg
• Bob Grant
• Joginder

Agenda

• Minutes from last Friday's call
• Administration - getting call notifications set up for list
• Entity status codes
• Ident Role Class
• Exposure Harmonization

Minutes from last Friday's call

• Motion to accept(Mead/Austin - no objections)

Administration - getting call notifications set up for list

• Lloyd want to see if we could get auto-notification of conference calls. This function has been disabled by HQ because it was causing spam related problems.
• Action: Craig will send out notifications Tuesday or Wednesday of each week.

Entity status codes

From Lee Coller:

We've discovered an inconsistency between the vocabulary ValueSet/Domain
for Entity.status and the state diagram for Entity.

According to the state diagram, the vocab elements are:
active
inactive
nullified

According to the vocabulary they are:
active
terminated
nullified

I personally favor the state diagram, as I think "inactive" makes
more sense then "terminated" (though I know Norman Daust disagrees
with me). In the interest of full disclosure I'm biased to these as
this is what we've used at Oracle.

Motion (Lee/Patrick) Approve a harmonization proposal to change the vocabulary from "terminated" to "inactive". We will mark "terminated" as deprecated in case there are existing implementaions using this. (no objections or abstentions)

Ident Role Class

See Use_of_IDENT_Role_Class

Current Text of Hot Topic

Issue: In the Specimen Domain we have a need to provide detailed information for the organization assigning a specimen identifier. Unfortunately, the Specimen (SPEC) Role is defined such that the scoper is not the organization issuing the identifier, rather the scoper is the parent entity the specimen was taken from. For instance, if blood is drawn from me, I become the scoper of the specimen role played by the blood. I certainly don't issue the identifier for the specimen. The IDENT Role seems perfect for handling this situation, if we can just use Role.code to indicate the id is for a specimen. The scoper of the IDENT Role would be the issuer of the identifier in this case. The Specimen role isn't the only role class code with this problem. The problem occurs with all the roles found in the RoleClassPartitive domain. The same problem seems to occur in the RoleClassOntological domain. The same issue seems to occur with many of the roles in RoleClassPassive. The general issue is that the scoper of these roles isn't likely to be the assigning authority for the identifier for the role.

Proposed Solution: For each role class code in the RoleClassPartitive, RoleClassOntological and RoleClassPassive domains, create a corresponding RoleCode value in a IdentifiedEntityRoleType domain. Additionally, create a new RoleLink type code that would be used to link the IDENT role to the associated role. The role link type could be something like IDENT, and it would indicate that the source role provides identification for the target role. The source role must be IDENT. The player entity of the source role is constrained to be the same as the player of the target role if present. If the player is absent from the source role, then it is assumed to be the same as the player of the target role.

Presumably the entity that plays the specimen role can play only one specimen role as there can be only one source for a specimen instance. Why is it not adequate to have that entity play other IDENT roles that are scoped by the issuer of the ID? That would be consistent with other areas (such as Person). LeeColler 17:12, 19 January 2007 (CST)

Agree. One entity, 2 roles (IDENT and SPECIMEN). The roles would have the exact same ID. There's no real need to associate the roles by another means than their playing entity. Rene spronk 01:43, 21 January 2007 (CST)

Outcome of Today's Discussion

To meet Lab SIG's use case for Specimen, Lab will use IDENT and role link.

We still need a concept domain for identifier types.