Difference between revisions of "MnM Minutes WGM 200709"
Line 155: | Line 155: | ||
'''Motion''': (Grahame/Kevin) Accept the proposed resolution. (5:0:0) | '''Motion''': (Grahame/Kevin) Accept the proposed resolution. (5:0:0) | ||
− | ==Wednesday Q1== | + | ==Wednesday Q1 & Q2== |
''Joint with Vocabulary'' | ''Joint with Vocabulary'' | ||
+ | ===Requirement to submit harmonization proposals via “Russ’s Tool”=== | ||
+ | MnM Motion: MnM endorses the requirement that vocabulary “encoded” submissions be submitted using the HL7 Harmonization Tooling. Exceptions will be granted for submitters who document why it was not possible to use the tool (e.g. unable to install or make the tool run, didn’t understand how to capture their proposal, tool had a defect, etc.). If the tool does not meet entry requirements, manual XML would also be accepted. Russ to provide a template (possibly in g-Forge) indicating the type of documentation desired for capturing reasons. Technical support (Russ, Woody & Jane) will be available for members. Russ will document system requirements for installation. | ||
+ | |||
+ | Moved: AMS/Woody/15/0/3 | ||
+ | |||
+ | ===Proposal to send concept id rather than mnemonic in messages except CS attributes=== | ||
+ | Significant discussion, concerns around whether it was appropriate to have rules that excluded structural attributes. Also concern about backward compatibility | ||
+ | Straw poll: Agree to use concept id instead of mnemonic 10/3/2 | ||
+ | Tabled for further discussion with others | ||
+ | |||
+ | ===Enhancements to v2 terminology to improve consistency with v3 approach to allow leveraging tools=== | ||
+ | |||
+ | Not MnMs mandate to decide, suggest talking to InM. However, in general “support” to use v3 vocabulary infrastructure in v2 is seen as a good thing. | ||
+ | Strategic plan – how vocab will keep themselves entertained | ||
+ | - finalize & ballot conceptual model (bindings, etc.) | ||
+ | - complete & ballot CTS 2 | ||
+ | - US Realm work – develop valuesets | ||
+ | - Permanent repository for value-sets | ||
+ | - Policy & procedures for US value-set binding approval | ||
+ | Balloting of binding rules | ||
+ | |||
+ | ===Issues from MIF alignment of LexGrid/CTS 2=== | ||
+ | No strategy for sorting codes and filtering print names in valueset definitions for use as picklists | ||
+ | |||
+ | ===Plans for next WGM=== | ||
+ | Want to do ballot resolution (at least some of it) as joint | ||
==Wednesday Q2== | ==Wednesday Q2== |
Revision as of 22:26, 20 September 2007
Contents
- 1 Sunday Q3
- 2 Sunday Q4
- 3 Monday Q1 and Q2
- 4 Monday Q3
- 5 Monday Q4
- 6 Tuesday Q1
- 7 Tuesday Q2
- 8 Tuesday Q3
- 9 Tuesday Q4
- 9.1 TemplateId for Semantic Markers
- 9.1.1 Can templateId be used to infer meaning?
- 9.1.2 Can designs require that templateId be asserted?
- 9.1.3 Can designs prohibit that unknown templateIds from being present?
- 9.1.4 Can implementers use templateId as a shortcut to understanding the semantics of an instance?
- 9.1.5 How can a template say "any template matching criteria X can go here?
- 9.1 TemplateId for Semantic Markers
- 10 Wednesday Q1 & Q2
- 10.1 Requirement to submit harmonization proposals via “Russ’s Tool”
- 10.2 Proposal to send concept id rather than mnemonic in messages except CS attributes
- 10.3 Enhancements to v2 terminology to improve consistency with v3 approach to allow leveraging tools
- 10.4 Issues from MIF alignment of LexGrid/CTS 2
- 10.5 Plans for next WGM
- 11 Wednesday Q2
- 12 Wednesday Q3
- 13 Wednesday Q4
- 14 Thursday Q1
- 15 Thursday Q2
- 16 Thursday Q3
- 17 Thursday Q4
- 18 Facilitators' Roundtable
Sunday Q3
Agenda Topics Review/Hot Topics Triage
Grahame suggested that we address the following issues:
- Incomplete Static Models (already a Hot Topic)
- Templates as Semantic Markers
- Translations in Data Types -- should we have a pattern for handling translations in the RIM
- Add "topic" to II
Note: There is interest in replacing CD qualifier and group with an expression. This will be addressed in Vocab.
We prioritized and scheduled Hot Topics. See updated schedule posted to the list server.
The following items were decided to be addressed on conference calls:
- ActReference - Aim to close on a conference call pending Grahame's confirmation that it is truly closed.
- Datatype Substitution Issues
- Model support for by reference
- Participation
- RIM Stewardship and Harmonization Representation -- Woody will document the resolution.
- Serialization - Action: The reference to the document needs to be added to the HDF.
Action: Resolve outstanding action items. We will discuss this in more detail on Friday Q2.
Action: Lloyd will talk about Observation Grab Bags at the Facilitators' Roundtable.
Motion: Grahame/Charlie - MnM recognizes that the infrastructureRoot attributes may be given special treatment in the ITS. (10:0:0) -- See "TemplateId as a token" Hot Topic
Action: Craig to notify MnM about this motion and we will finalize it at roundtable.
Sunday Q4
No meeting.
Monday Q1 and Q2
No meeting - HL7 Plenary Session
Monday Q3
Joint with INM: wrappers and dynamic model
We reviewed the dynamic model discussion from the last Harmonization meeting.
Charlie presented MCAI_DM700200UV02. We discussed the addition of ConversationId. The need for ConversationId was generally agreed upon.
Conclusion #1 from INM_assumptions_with_regards_to_CPM:
INM will introduce the concept of "conversation ID" in the new controlAct wrapper to link all interactions in a conversation.
Motion: Grahame/Charlie -Move accept Conclusion #1 from INM_assumptions_with_regards_to_CPM. (motion passes, 14:0:2)
Conclusion #2 from INM_assumptions_with_regards_to_CPM:
INM will introduce the concept of "conversation code" in the new controlAct wrapper to identify the type of conversation.
Motion: Grahame/Charlie - Move to accept Conclusion #2 from INM_assumptions_with_regards_to_CPM. (motion passes, 15:0:1)
The question was raised as to wether MnM would support an ITS introducing grouping mechanisms that are not explicitly modeled at the ITS-independent level.
Motion: Charlie/Woody - MnM endorses the idea that an ITS can provide a mechanism for reducing duplication of data so long as its behavior is not predicated on the semantic model. (motion passes, 12:0:3)
Monday Q4
Joint with Templates: Ballot resolution (Incomplete Static Models; Template references by type; TemplateId for Semantic Markers)
Incomplete Static Models
There are times when we want to specify a template that enforces only a small part of a large model.
There was discussion of the whether it is appropriate to use the words "derivation" and "extension" in how the MIF relates models to each other.
Action: Craig to create a Hot Topic on "Derivation".
Motion: Grahame/Ian - Agree to the updated wording in the Extension section of the Incomplete Static Models Hot Topic (included below) (motion passes, 5:0:7)
From the Incomplete Static Models Hot Topic
Definitions:
- Derivation - [no consistent existing understanding or definition]
- Constraint/Extension - models may be constraints or extensions of other models. (models may also be incompatible)
Context
- Templates may be derived from a particular model, and may be related to other models as identical, constraints, extensions, or incompatible
Rules
- Incomplete templates are always *derived* from the RIM and are also always constraints on the RIM.
- A model may be applied as a template on another model if it is either a constraint or an extension (or, most usefully, both) but not if it is incompatible.
- Only LIMs are allowed to contain incomplete classes (for now).
- Incomplete templates cannot be used as expressed models
[Note that there is an pending outstanding hot topic that Lloyd will create that will further discuss the relationship between derivation, constraint and extension, but for now these rules are adopted in the interim period)
Tuesday Q1
No meeting.
Tuesday Q2
No meeting.
Tuesday Q3
No meeting.
Tuesday Q4
Hot Topics
Atendees:
- Lloyd
- Graham
- Dick Harding
- Kevin Coonan
- Craig Parker
- Woody Beeler
TemplateId for Semantic Markers
Can templateId be used to infer meaning?
Current position: No. Meaning must be understandable from structuralCodes, other vocabulary and the construction of the message. I.e., An application must not use templateId to avoid sending elements within an instance that would otherwise normally be sent to convey the semantics represented by the template.
you should gain no further understanding from a message instance by reviewing the content of the message instance than you would by looking up the templateId.
Proposed Resolution: Retain the current position.
Motion: (Grahame/Craig) Accept the proposed resolution. (5:0:0)
Can designs require that templateId be asserted?
Current position:
- In CDA; yes.
- In messaging; no (at least so far). Expectation is implementers must implement the full message structure. Support for templates is always optional.
- In SOA; ???
Issues: NHS currently requires this to ensure efficient processing.
Discussion: There's no real harm in allowing implementations to require that templateIds be present. However, this must be done in the "normative" specification. Private implementations that fail to process messages no aserting local templates would be considered non-compliant.
Proposed Resolution: We will allow committees and affiliates to require that certain templates be asserted in instances. We will also allow implementations to require templateId to be asserted in instances, though such applications may be deemed to have a "reduced" level of conformance (discussions of "conformance levels" and what they constitute will be deferred to a future meeting).
Motion: (Grahame/Dick) Accept the above proposed resolution. (4:1:0)
Can designs prohibit that unknown templateIds from being present?
Current position: No. Unrecognized templates must be ignored.
Proposed Resolution: Retain the current position.
Motion: (Grahame/Craig) Accept the proposed resolution. (4:0:1)
Can implementers use templateId as a shortcut to understanding the semantics of an instance?
Current position: Unclear.
Proposed Resolution: Yes. TemplateId can be used in a similar manner to typeId, flavor and other instance markers to allow invocation of tuned processing specific to the template, message type or datatype flavor.
Motion: (Grahame/Kevin) Accept the proposed resolution. (5:0:0)
How can a template say "any template matching criteria X can go here?
Current state: We have MIF support saying "this template" or "one of these templates" must go here by using CMESs and choices of CMETs.
Proposed Resolution: Make use of the existing "stub" capability in the MIF. However, add the ability when referencing a stub to assert a "model constraint". (E.g. must have an Act.code constrained to Domain Y or some specialization.) This will limit the set of models (e.g. templates) that can be bound to the stub to be those that match both the kind of stub and those for which the model constraint is true. The addition of the model constraint will require a MIF change and will require selection of an appropriate meta-level constrain language.
Motion: (Grahame/Kevin) Accept the proposed resolution. (5:0:0)
Wednesday Q1 & Q2
Joint with Vocabulary
Requirement to submit harmonization proposals via “Russ’s Tool”
MnM Motion: MnM endorses the requirement that vocabulary “encoded” submissions be submitted using the HL7 Harmonization Tooling. Exceptions will be granted for submitters who document why it was not possible to use the tool (e.g. unable to install or make the tool run, didn’t understand how to capture their proposal, tool had a defect, etc.). If the tool does not meet entry requirements, manual XML would also be accepted. Russ to provide a template (possibly in g-Forge) indicating the type of documentation desired for capturing reasons. Technical support (Russ, Woody & Jane) will be available for members. Russ will document system requirements for installation.
Moved: AMS/Woody/15/0/3
Proposal to send concept id rather than mnemonic in messages except CS attributes
Significant discussion, concerns around whether it was appropriate to have rules that excluded structural attributes. Also concern about backward compatibility Straw poll: Agree to use concept id instead of mnemonic 10/3/2 Tabled for further discussion with others
Enhancements to v2 terminology to improve consistency with v3 approach to allow leveraging tools
Not MnMs mandate to decide, suggest talking to InM. However, in general “support” to use v3 vocabulary infrastructure in v2 is seen as a good thing. Strategic plan – how vocab will keep themselves entertained - finalize & ballot conceptual model (bindings, etc.) - complete & ballot CTS 2 - US Realm work – develop valuesets - Permanent repository for value-sets - Policy & procedures for US value-set binding approval Balloting of binding rules
Issues from MIF alignment of LexGrid/CTS 2
No strategy for sorting codes and filtering print names in valueset definitions for use as picklists
Plans for next WGM
Want to do ballot resolution (at least some of it) as joint
Wednesday Q2
Joint with Vocabulary
Wednesday Q3
Technical Editing Project
Wednesday Q4
Joint with Publishing
See Publishing minutes.
Thursday Q1
Joint with INM & HSSP.
See INM minutes.
Thursday Q2
No meeting.
Thursday Q3
No meeting.
Thursday Q4
No meeting.