MnM Minutes WGM 20080115

Monday Q1

Hot topic: update mode

Attendees

• Dale Nelson (scribe) (dale@zed-logic.com)
• Rik Smithies (rik@nprogram.co.uk)
• Tim Ireland (Tim.Ireland@nhs.net)
• Norman Daoust (Norman@DaoustAssociates.com)
• Grahame Grieve (grahame@kestral.com.au)
• Andrew Hinchley (andrew.hinchley@cerner.com)
• Keith Naylor (keith.naylor@nhs.net)
• Ioana Singureanu (ioana@eversolve.com)
• Lee Coller (Lee.Coller@oracle.com)
• Charlie McCay (charlie@ramseysystems.co.uk)
• Lloyd Mckenzie (lloyd@lmckenzie.com)
• Woody Beeler (chair) (woody@beelers.com)

Agenda: Hot topics/update mode Grahame Grieve (GG) presented concerns related to "Update Mode" when preparing Abstract Data Types Release 2:

1. Clarity on terms and definitions
2. Clarity where update mode is documented and how much information data types needs to contain?

   The update mode descriptions in the HDF do not seem to agree with Abstract Data Types R2 Table 59.

The group discussed possible documentation options, and suggests the following:

Prepare a new document in the ballot package in V3 Foundation, before Reference Information Model. Initial title is "Core Properties of V3 Models". An initial outline (below) was discussed but has been superseded by th evolving document found at Core_Properties_of_V3_Models

• Introduction to how RIM & data types fit together
  • principles
  • classes
  • properties
    • cardinality
    • mandatory / conformance
  • attributes
    • vocabulary concepts & coding strength
  • associations
• concepts
  • nullFlavor
  • typing (typeId & flavorId & templates)
  • conformance & testing
  • update principles
  • referencing principles
  • updateMode
    • use cases
  • data types

Motion: Grieve/McKenzie (9-0-2) That MnM ballots this document described above for normative track; Woody Beeler and Grahame Grieve will be co-authors for this coming ballot cycle. “update mode” will be renamed at the abstract level to “usage mode”.

Ballot reconciliation on Abstract Data Types

MnM took on various data type abstract ballot negatives, referred from InM. Following reference line items from Ballot reconciliation spreadsheet.

Line 141 (Grieve/Coller 11-0-0)

Line 142 (Grieve/Coller 11-0-0) If the item was (or is to be ) added, having not been present immediately before. (If it is already present, this may be treated as an error condition)

Line 143 (Grieve/Beeler 11-0-0) If the item existed previously and has (or is to be) revised. (If an item does not already exist, this may be treated as an error condition)

Line 146 (Grieve/Beeler 11-0-0) It is not specified whether or what kind of change has occurred to the item.

Monday Q2

Agenda: Hot topics - Interaction & Versioning, V3 Substantivity

Attendees

• Dale Nelson (scribe) (dale@zed-logic.com)
• Tim Ireland (Tim.Ireland@nhs.net)
• Norman Daoust (Norman@DaoustAssociates.com)
• Andrew Hinchley (andrew.hinchley@cerner.com)
• Keith Naylor (keith.naylor@nhs.net)
• Ioana Singureanu (ioana@eversolve.com)
• Charlie McCay (charlie@ramseysystems.co.uk)
• Lloyd Mckenzie (chair) (lloyd@lmckenzie.com)
• Woody Beeler (woody@beelers.com)
• Dan Anderson (daniel.anderson@imail.org)
• Rene Spronk (rene.spronk@ringholm.com)
• Abdul-Malik Shakir (shakir@cs.com)

Discussion:

What are rules for semantic backwards compatibility? They conflict with ISO definition.

How is versioning, backwards compatibility related to interaction version (in its name), profileid, etc.?

Could evaluate whether new artifacts (compliant with the new/modified model) can be parsed by the current schema.

Some say: “I conform to the implementation guide of 2006” e.g.

In Canada, everywhere a schema is constrained, a new artifact is created. So, perhaps the question is to use a realm.

Rene: We should encourage use of universal artifacts. Pure constraint on a UV then used in a realm model. (e.g. remove some classes, and change schema to reflect)

After much discussion voted on a motion to accept the following assertion:

Assertion:

Supporting an artifact id (interactionId, typeId) means that:

• the application uses the semantic model associated with that id (plus possible ‘ignorable’ extensions)
• the application uses the syntax associated with an ITS implementations of the artifact
• it does not NOT mean full support for the content expressed by the artifact
• definition of exactly what content is supported is determined by the profileId
• applications MAY raise errors when instances do not declare a recognized profile or do not comply with one of the declared profiles.
• Interoperability requires knowledge of both artifactId and profileId.
• In the absence of a profileId, the expectation is that the receiver will fully support any instance allowed by the artifact, though it may ignore elements with conformance of optional (blank) and must ignore non-supported extensions.

In order to reconcile historical use in CDA, should recommend that profileId be added to CDA for R3.

Motion: (McCay/Spronk 9-0-2) MnM recommends to Implementation & Conformance that the above assertion be adopted and reflected in the Refinement and Localization document.

Continuing discussion

1. Under what circumstances should realms create “realm” artifacts (as opposed to UV)
   • some constraints cause schema element name changes in XML ITS
   • other constraints are just restrictions with no element name changes

   If instances created against the realm constraint would not validate against the UV specification (for any ITS), it must be treated as a realm artifact (a new artifact id must be issued for that realm code).

   NOTE: “extension” elements using foreign namespaces or other flags do not impact the above analysis because conformant applications are required to ignore them during validation.

In other circumstances, you MAY create a new artifact or MAY reference the UV artifact as well as a profileId with realm constraints.

Pro’s of the new artifact:

• places all constraints in a single specification, simplifies testing

Pro’s of the UV version:

• enables determination of interoperability possibility between cross-realm applications.
• simplifies determination of forward and backward compatibility by separating constraints from syntax

The following will be discussed Friday Q2:

1. When realms reference UV models “with constraints”, need to reference versions of constraints separate from UV interaction version.
2. CDA has a different definition for backward compatibility than our “semantic backwards compatibility” definition.
3. ISO term for what we call “backward compatibility” is “forward compatibility”
4. Sometimes users adopt artifacts prior to “freezing” at ballot, which is when version ids are assigned. How do they tell what ‘non-official’ version they’re referencing?

Tuesday Q1

HDF Ballot Reconciliation

Attendees

• Bernard Jackson (BERNARD@exchange.clemson.edu)
• Susan W. McClacherty (susan.mcclacherty@khpa.ks.gov)
• Scott Robertson (sScott.M.Robertson@kp.org)
• Ioana Singureanu (ioana@eversolve.com)
• Freida Hall (Freida.Hall@va.gov)

The committee reviewed the comments submitted by Kaiser Permanente. Scott Robertson indicated that Kaiser will withdraw the negative assuming that the proposed resolutions are applied in full.

--Ioana13 16:56, 15 January 2008 (CST)

Tuesday Q2

HDF Ballot Reconciliation

Attendees

• Lee Coller (lee.coller@oracle.com)
• Susan W. McClacherty (susan.mcclacherty@khpa.ks.gov)
• Scott Robertson (Scott.M.Robertson@kp.org)
• Sina Mowzoon (Sina.Mowzoon@azahccs.gov)
• Ioana Singureanu (ioana@eversolve.com)
• Freida Hall (Freida.Hall@va.gov)
• Kathleen Connor (Kathleen.Connor@foxsys.com)

The committee reviewed the comments submitted by Virginia Lorenzi, Jane Curry, and VA. The changes resulting from the comments provided by VA will be substantive.

--Ioana13 16:56, 15 January 2008 (CST)

Wednesday Q1

Discussion opened on further details underlying the definition of bindings between domains and value sets for use in HL7 models. Vocabulary provided preliminary "rules" for approval of such binding for discussion. This resulted in a motions to support the following recommendations which will be placed in the new "Core Properties" document (See Monday Q1) for ballot.

Recommended principles:

1. Universal context binding approvals for RIM structural attributes and modifications to value-sets in those bindings only require harmonization approval. Data types bindings are handled through the abstract data types ballot. Model bindings are approved through the ballot process. The Affiliates Council is not consulted for any of these.
2. Representative bindings are approved at harmonization only, and multiple representative bindings may exist for the same domain. No weighting shall be associated with different representative bindings for the same domain.
3. Universal bindings to domains for non-structural attributes and for data type properties not bound in the Abstract specification, require harmonization approval and Affiliates Council approval. Subsequent modifications and modifications to value-sets in those bindings require similar approval. (Note that modifications to the code systems underlying the value-set definition does not require Affiliate Council approval.)

Motion: (Beeler/Hamm: 9/0/5) MnM approve the principles above and forwards them back to Vocabulary and the Affiliates Council for final decision

Names for types of binding

Discussed the "names" to be applied to bindings that are defined in two ways. The full definitions are in a separate document, but briefly, one is the definition of a binding to be mandated within a given context (frequently a realm) while the other are bindings defined as a model (message, profile, etc) is defined and approved. The previous names were confusing.

Vocabulary proposed new names that were not confusing, but that some found cumbersome for use. Ultimately, the meeting tool a formal motion as follows:

Motion: (Beeler/Huff: 11/0/2) Agreed to a change the designated names for two different forms of binding. (Changes are to be made in existing documentation.) Previous usage of "Runtime binding" will become "Context binding", and previous usage of "Design-time binding" will become "Model binding".

Thursday Q1

Agenda topic: Joint with I&M, ITS and HSSP - Dynamic model

HSSP has a tool they think will work for the dynamic model and will be experimenting with it, with plans to seek formal approval for its use within services by next WGM. M&M members are encouraged to read through their whitepaper and also experiment with the tool.

Thursday evening

Facilitator's Round Table

Received and collected issues from Facilitators.

Scheduled harmonization dates for 2008 are:

• April 1-4, 2008 in Las Vegas, NV;
• August 12-15, 2008 in Boston, MA, Park City UT, or Traverse City, MI;
• November 11-14, 2008 in Washington, DC or Alexandria, VA (following AMIA)

M&M Meeting Highlights

Sunday Q3

Triaged Hot Topics and finalized agenda

Sunday Q4

Hosted introduction to new Tool capabilities, including:

• new vocabulary capabilities of RoseTree (including Tile Views)
• new OHT Eclipse-based example instance editor
• new NHS MIF-differencing capability

Monday Q1 – Hot topics - Update mode

Discussion of Update Mode noted that agreed-upon changes were not presented in most recent HDF publication and were not correctly represented in Vocabulary.

Broader discussion led to motion to create a new normative artifact, to be presented for Committee ballot in the May 2008 cycle, that defines key concepts and “rules” that are used to link together the core normative models – RIM, vocabulary, data types – as these are used in the development and implementation of V3 standards.

Monday Q2 – Conformance to Versioned artifacts

Initial discussion focused on how an application can claim to conform to or support an HL7 artifact identified by an interaction identifier (artifactId), a type identifier (typeId) or a template identifier (templateId). The following was adopted and is believed to incorporate current usage within CDA and message communication.

“Supporting” an artifactId (interaction or message type) means:

• The application uses the semantic model associated with that id (plus possible 'ignorable' extensions)
• The application uses the syntax associated with an ITS implementation of the artifact
• it does not mean full support for the content allowed by the artifact
• definition of exactly what content is supported is determined by the profileId
• applications MAY raise errors when instances do not declare a recognized profile or do not comply with one of the declared profiles.
• Interoperability requires knowledge of both artifactId and profileId
• In the absence of a profileId, the expectation is that the receiver will fully support any instance allowed by the artifact, though it may ignore elements with conformance of optional(blank) and must ignore non-supported extensions.

Note: Historically, CDA uses templateId or typeId as profileId. It will be recommended that profileId be added to CDA for Release 3.

Tuesday Q1, Q2 – HDF Ballot Reconciliation

The committee reviewed the comments submitted by Kaiser Permanente. Scott Robertson indicated that Kaiser will withdraw the negative assuming that the proposed resolutions are applied in full.

The committee reviewed the comments submitted by Virginia Lorenzi, Jane Curry, and VA. The changes resulting from the comments provided by VA will be substantive.

Tuesday Q4 – Joint with I&M

Joined I&M Committee to participate in ballot reconciliation on Abstract Data Types, Release 2.

Wednesday Q1 – Joint with Vocab

Met with Vocabulary to discuss binding of vocabulary constraints to static models. Agreed that the new document (see Monday Q1) will include vocabulary binding as developed over past several WGM and being discussed today. Subject to further review in Vocabulary, agreed to the following principles for approving bindings:

1. Universal context binding approvals for RIM structural attributes and modifications to value-sets in those bindings only require harmonization approval. Data types bindings are handled through the abstract data types ballot. Model bindings are approved through the ballot process. The Affiliates Council is not consulted for any of these.
2. Representative bindings are approved at harmonization only, and multiple representative bindings may exist for the same domain. No weighting shall be associated with different representative bindings for the same domain.
3. Universal bindings to domains for non-structural attributes and for data type properties not bound in the Abstract specification, require harmonization approval and Affiliates Council approval. Subsequent modifications and modifications to value-sets in those bindings require similar approval. (Note that modifications to the code systems underlying the value-set definition does not require Affiliate Council approval.)

Agreed to a change in the designated names for two different forms of binding. (Changes are to be made in existing documentation.) Previous usage of “Runtime binding” will become “Context binding”, and previous usage of “Design-time binding” will become “Model binding”

Thursday Q1 – Joint with I&M, ITS and HSSP

HSSP has a tool they think will work for the dynamic model and will be experimenting with it, with plans to seek formal approval for its use within services by next WGM

M&M members are encouraged to read through their whitepaper and also experiment with the tool.

Thursday evening – Facilitator's Roundtable

Received and collected issues from Facilitators.

Selected harmonization dates for 2008 are:

• April 1-4, 2008 in Las Vegas, NV;
• August 12-15, 2008 in Boston, MA, Park City UT, or Traverse City, MI;
• November 11-14, 2008 in Washington, DC or Alexandria, VA (following AMIA)

Friday Q1

Wrote this report and prepared the preliminary agenda for May 2008