This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

MnM Minutes WGM 200709

From HL7Wiki
Revision as of 20:45, 18 September 2007 by Cgpmd (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

  1. Incomplete templates are always *derived* from the RIM and are also always constraints on the RIM.
  2. 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.
  3. Only LIMs are allowed to contain incomplete classes (for now).
  4. 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)