MnM Minutes CC 20070209

February 9, 2007

Attendees

• Lloyd McKenzie
• Woody Beeler
• Craig Parker
• Austin Kreisler
• Lee Coller
• Kristi Eckerson
• Mead Walker
• Patrick Loyd
• Gregg Seppalla
• Bob Grant
• Joginder Madra

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.

Mead and Austin will draft harmonization proposals to address this item.

Motion to endorse Austin's proposal for a new role link of type IDENT (Austin/Patrick - no objections, 2 abstentions) Motion passed.

CMETS

Motion that MnM approves the balloting at draft, committee, and membership the CMET ballots. (Dale/Austin - no objections, 1 abstention)

Dale solicited a list of CMETs from those participating on the call.

Exposure Harmonization

Discussed proposal for harmonization of Exposure and SubstanceAdministration concepts that was sent to M&M lists this AM. This resulted from two 4-hour PHER-sponsored "Exposure Summit" Meetings to figure out an approach to Exposure modeling.

Proposal does "undo" the Exposure-SubstanceAdministration hierarchy, making them siblings.

Two remaining issues were deferred to today

1. - Relation to SubstanceAdministration has been addressed in the written proposal. Exposure transmission is an SA. This also provided a specific set of words that distinguished the two.
2. - Clarification of the definition of SubstanceAdministration. Mead Walker will prepare a proposal to re-visit the SubstanceAdministration definition. Issues lie in the area of intentionality.

Review process in PHER will continue today, but goal is to get this proposal on the Harmonization Meeting as a CoverPage. It may undergo some change between now and final deadline, but the major structure will not change.

No formal action from M&M but to make us aware of the proposal and the importance of reviewing this as a single package.

M&M approved a motion to endorse this proposal going forward. Austin Kreisler moved, Kristi Eckerson seconded. Unanimous.

INM Proposal for conversationID and conversationType attributes in ControlAct

Received an e-mail request from Rene Spronk that said:

INM has adopted a motion related to the concept of "conversation ID" (business process conversation). This is a static model solution which covers the existing as well as the envisioned new dynamic model. INM won't be able to wait for the new dynamic model to be finalized. The attributes would end up in the Conversation class in the http://informatics.mayo.edu/wiki/index.php/Behavioral_Contract_Wrapper_%28new_wrapper_mechanism%29

MnM review is requested to see if there are any methodology issues.

See http://informatics.mayo.edu/wiki/index.php/INM_assumptions_with_regards_to_CPM for the motion and the reasoning behind it.

M&M had some discussion of the status of the new dynamic model and the implications of this proposal. [Beeler note: We should have, but did not, observe that neither attribute should have the word "conversation" in its name since they are being proposed for a "Conversation" class. The attributes should be just "id" and "typeCode."]

M&M did consider a "sense of the meeting" motion - Patrick Loyd moved, Lee Coller seconded, passed unanimously. The send of the meeting motion reads:

"M&M has no objection, in principal to Conversation.id and Conversation.typeCode, indeed they seem logical extensions, but we wishes to defer formal review until the new dynamic model is closer to adoption."