MnM Minutes WGM 200809

September 2008 WGM Vancouver, BC

Sunday, September 14, 2008, Q3

Agenda & Hot Topics Triage

Agreed on Agenda Hot topics for discussion

Agreed: Motion wehen update core principles we write that update mode owrks on equality for both RIM attributes and data types. Grahame moved, Patrick Loyd seconded. 17-0-2

Sunday, September 14, 2008, Q4

V3 Generator update

Monday, September 15, 2008, Q1-2

No committee meeting. Annual Plenary Meeting.

Monday, September 15, 2008, Q3

Made revisions to negationInd harmonization proposal. These changes will be presented to the facilitators on Thursday evening.

Motion to approve harmonization proposal 010104 - Lloyd/Craig (5:0:0)

Motion to approve harmonization proposal 010105 - Lloyd/Dale (5:0:0)

Monday, September 15, 2008, Q4

Motion to do the following: - Ballot the RIM on an annual basis. - Adopt Jay Lyle's revisions in the next round of balloting. - Woody to be the project lead and will file the project scope statement. Dale/Andy (7:0:1)

Agreed to proceed with balloting of Core Principles.

Design Patterns Grahame will lead this project. Grahame and Woody will prepare the scope document. Grahame will deliver a document to frame the design patterns for discussion on November 11 at the Washington DC harmonization meeting.

Context Conduction Lloyd will lead an effort to get a group together to discuss the issues around context conduction and develop a strategy for addressing the problems. This will likely be a two quarter meeting in Orlando. Woody will launch this as a project. Grahame volunteered to participate.

Tuesday, September 16, 2008, Q1-2

No Quorum

Tuesday, September 16, 2008, Q3

Hot Topics

Lloyd will publish guidelines for getting SVN versions embedded in Visio artifacts so they show up in generated models. (And get the other SVN version stuff working too)

Namespacing of artifacts

Requirements 1. Need to ensure that locally created artifacts don’t collide with someone else’s locally constrained artifacts
a. Solution: For now, register your own 2-character “realm namespace” with the Vocabulary WG to allow you to namespace your artifacts. In the future, artifact ids will no longer be fixed length, allowing realm namespaces greater than 2 characters, as well as using OIDs for namespace ids for those who don’t want to register them.

2. Need to have version differentiation for artifacts that have not passed normative or DSTU ballot. (Required for “pre-adoption”, as well as hot-fixes/technical corrections)
a. Solution: Near term: Could use date-timestamp of source files, though this doesn’t currently propagate for all artifacts. Soon can expose ability to capture SVN version id and propagate it.

3. Must be able to implement a previously published interaction version using new “infrastructure” (updated vocab, datatypes, RIM, wrappers, CMETs, ITS, transport protocol)
a. Solution:

4. Must be able to identify when you process an instance what “definitions” apply – including local extensions, datatypes, vocab, wrappers, cmets, message types, receiver responsibilities. (Definitions could be schemas, MIF, etc.)
a. Solution:

5. Need a way of programmatically sharing definitions of localizations on static model and dynamic model artifacts. I.e. How do you electronically express conformance profiles/implementation guides?
a. Solution:

6. Need to manage the fact that an artifact could need to declare itself against multiple specs it complies with (e.g. UV, CA, BC)
a. Solution:

7. Need to know in generated artifacts the “versions” of all artifacts on which the generation was dependent. (Versions of tools would be good too.)
a. Solution:

8. Need to be able to test and indicate that 2 different “profiles” are compatible for a given interaction. (Because profiles may involve multiple interactions, some of which won’t have changed, or will have changed in a backward-compatible way.)
a. Solution:

	Static Profile	Imp. Profile	*_Id (static models, int, etc.)	Version #
UV
- Ballot
- DSTU/Norm
- Editions
Affiliate
- Ballot
- DSTU/Norm
- Flavors/Variants
Province
Hospital

Each Box:

• Contents
• Covernance
• How Derived
• Today/Future
• Testing Expectations
• Uniqueness Criteria

Group will meet Thursday Q1 as will as schedule Hot Topic time on upcoming MnM calls.

Tuesday, September 16, 2008, Q4

No committee meeting.

Wednesday, September 17, 2008, Q1

All static model vocabulary bindings are captured normatively in MIF (1.1 or 2.1), the same as all other static model constraints

Renderings of the MIF are used to communicate these constraints to “humans”.

At present, all HL7 renderings included in the V3 ballot expose the vocabulary constraints, specifically table view, Excel view, Visio diagram png and schema

Other renderings SHOULD expose vocabulary constraints where vocabulary is relevant to the intended audience.

Implementation guides and profiles SHOULD express their static model constraints in MIF. (This is the only programmatic expression for vocabulary constraints.)

The normative representation for “Context bindings” and definitions of Binding Realms is also maintained in MIF (Vocabulary 2.1).

Affiliates are responsible for maintaining the context bindings for all binding realms controlled by that affiliate. Affiliates SHOULD publish these bindings in MIF format. The binding realm namespace is (presently) universal, maintained by HL7.org.

Static models identify the vocabulary model they are based on. Vocabulary models may depend on other vocabulary models. All vocabulary models must depend on an HL7 UV vocabulary which contains binding realm definitions and concept domain definitions.

Binding realms are only maintained by HL7 UV or an affiliate? (Woody’s use-case: Location “codes”)

Issue for future discussion: Can affiliates identify certain Concept Domains as “for local binding”, which allows local jurisdictions to define their own binding realms?

(We will then have an issue of how to maintain binding realms – which are currently in a universal namespace.)

When do you use context binding (and leave your static models referencing concept domains) and when do you use model bindings using templates or profiles that reference explicit value sets? • When a given value-set assertion applies across a large number of static models that are defined at a level “above” the interoperability area, use context binding (i.e. you have agreement within a context binding interoperability space) (I.e. if you’re using UV models, but can only get agreement on value sets at the national level, context binding is appropriate.) • “Template” model bindings are particularly useful when a single valueset can’t be asserted across all models, but can apply at an “instance” level for a given problem space and the model structure or pattern appears in many message structures. • Regardless, ensure bindings (static or context) are only performed at the level where you can get consensus, because once bound, compliant instances have vastly reduced flexibility.

All of the above should be documented in the Core Principles.

Value set “conformance”

• There’s a need when binding value sets or defining value sets to be able to differentiate the “conformance” expectations for the codes in that value set, similar to how conformance is asserted for attributes. I.e. Are they “required”, “not supported” or “undeclared (optional)”. It may be that some codes in the value set might be “Required”, while others remain “Undeclared”.

(There might be a requirement to distinguish further about what sort of “support” is expected for required codes – i.e. required for display or for capture. Similar requirements might apply to attribute conformance too.)

There might be a need to have different value sets for sending and receiving. E.g. When receiving, all codes are required. When sending, some or all codes are optional. Mechanism to clarify this use when doing a context binding needs to be clarified a bit. Perhaps by distinguishing the concept domains for receiving vs. sending?

Would it be possible to define multiple context bindings (Concept Domain, Binding Realm, Value Set) with a property that differentiates “for sending”, “for receiving” or “both”?

Lloyd, Jane & Ted will put together a proposal for “code conformance” to be discussed on a future vocabulary call. Will try to coordinate some MnM & Vocab joint calls. Will do final refinements at the interim meeting and include the resulting content in the next release of the Core Principles document.

At the next WGM, do Wed Q1 and Q2 joint MnM and Vocab

Wednesday, September 17, 2008, Q2-3

No committee meeting.

Wednesday, September 17, 2008, Q4

Hosting InM

Direct and Indirect conformance

• There’s a strong opinion by many implementers that our XML instances are overly complex.
• There’s a need for healthcare applications to support messages that are developed in other standards or disciplines (finance, social services, etc.)
• There’s a need for external organizations to “use” the HL7 semantic model within their own structures

ITS is effectively a mapping of a semantic model to a given implementation model. Suggest was to provide separate implementation models to address above use-cases.

Concern that lots of implementation models will cause interoperability issues.

Possibility is to provide a different form of conformance statement “I conform to the ‘semantic model’, but use my own serialization format”. I.e. No wire format interoperability, but convey identical semantic information.

Concern is that interoperability will be an issue.

Word “transform” is problematic. Words “mapping” or “translation” are ok (because they don’t imply XSLT”.)

Question: Can we enforce/assume that all implementation models will be XML?

Publicly available machine executable conversion process to an HL7 static model.

Whether it’s bi-directional determines “level” of conformance.

Whether the conversion is to a RIM-based static model or a balloted artifact affects “level” of conformance

Motion: Charlie/Andy 6/0/0

• MnM and Implementation/Conformance are comfortable with the idea of labeling an application or another protocol as “HL7 Semantically Conformant” with a published version of a HL7 static model or interaction definition. However, this label would require that there is a publicly available, machine executable conversion process to and/or from a standard HL7 ITS expression of that static model or interaction where the standard HL7 ITS instance must be fully compliant with that published version. Conversion must be done in such a way that the semantics are maintained.

Next steps:

• Lloyd will highlight this to MnM to facilitators at the Thursday night round-table
• Charlie will ensure this gets validated against the ARB’s enterprise architecture
• Charlie will pass this on to John Quinn’s task force on backward compatibility
• This should be documented in Refinement, Constraint & Localization.
• I&C will discuss and determine the schedule to ballot this content
• Need to document rules for “behavior” part of the model as well. I.e. conformance to receiver responsibilities must be retained.
• Need to modify conformance profile MIF to support this type of conformance. (e.g. URL to publicly available conversion process)

Formal representation of conformance profiles

• Suggestion that I&C review the MIF format as it is – may be too complex some places, too simple other places.

No current tool does full v3 conformance profiles and exports to MIF. Canadian tool does a subset of conformance profiles, but no export function and probably not a good foundation for such a tool.

Once new v3 behavioral model is fully defined (presuming it uses Eclipse-based tools), then building an interface on top of that that integrates and adds the additional meta-data relevant to conformance profiles and implementation guides might be appropriate and “relatively” easy to do.

Tooling for conformance profiles could begin in parallel with tools for behavioral representation and complete shortly there-after. Certainly requirements analysis and validation can begin now.

Thursday, September 18, 2008, Q1-4

No committee meetings

Thursday, September 18, 2008, Facilitators’ Roundtable

Future Harmonization Meetings

• April 14 - 17
• Las Vegas, NV

• August 18-21
• Traverse City, MI

• November 17-20
• San Francisco, CA
• Note: AMIA is Nov 14-18 in SF

Updates by Woody

• Woody reviewed the new decisions for balloting of CMETs as defined at the last harmonization meeting.

Committee Reports

RCRIM Jennifer Neat

• Questions about submitting vocabulary for harmonization.
• Questions about external code systems.
• Can the attribute to have a fixed value? Lloyd says yes. Will follow up with Lloyd

Gunther

• Discussion about the role of a DAM is happening in RCRIM. Is a DAM required? There was some question about the HDF addressing this. There were further questions about the current state and status of the HDF.

Structured Product Labeling Gunther

• SPL passed ballot
• Good progress on the common product model.
• There was a question about Entity.quantity being constrained to a cardinality of 1 for instances. This will likely surface as a harmonization proposal.

Education AMS

• The education committee has received comments that some tutorials are giving out misinformation. He invited folks with domain expertise to sit in on some of the tutorials. Interested people should contact AMS.
• There is concern about the ability to get tutorial speakers for Kyoto.

Clinical Genomics Amnon

• The issue was raised that the roadmap makes no reference to V2. This raises concerns about maintaining alignment between V2 and V3.

Patient Administration Gregg

• How should an organizational hierarchy be represented without a lot of overhead? To be discussed at a future date.
• Several of the CMETs that passed ballot actually had the wrong models associated with them. PA seeks guidance on an out-of-cycle ballot to try to get these in the next normative addition. It was determined that there would not be time to complete such a ballot before publication of the 2009 Normative Edition. The content will be included, but will not be identified as normative.
• Some DSTUs passed with the wrong wrappers. Since these are DSTU, this can be fixed without reballoting.

Emergency Care Kevin Coonan

• Asked for a clarification of the definition of an encounter. He was referred to the PA ballot.

Financial Managment Kathleen

• Reported on the status of several ballots.
• Would like to start using the UML approach for balloting. The working group was told that anything that came out from this method could only be informative.
• Agreed to being a consumer oriented project.

Lab Austin

• Lab Result topic has passed normative.
• Lab may recombine with OO as early as January.

Public Health Emergency Response Austin

• Transferring responsibility for the TB DAM to CIC.

Structured Documents Bob Dolan

• Have put out 5 different ballots for CDA implementation guides. They are being published as DSTUs. They are looking to build tooling support to help in this.
• The issue of whether an "author" could be a machine arose this week. Patrik pointed out that they had a similar concern with "data enterer".
• There was discussion about whether the mood for an order set should be EVN or DEF. The current resolution is that SDA will only allow EVN mood and order set will be consistent with SDA.

OO Patrick

• Working to get their requirements into the ArB's behavioral model effort.
• Would really like to have cascading descriptions in publishing.
• Clinical Statement has been spun off as a Working Group.

ITS Dale

• Decided to release datatypes R1.1 as a backward compatible interim solution until R2 is completed. This is an XML syntax based on the R2 abstract data types. There are no concrete plans for a transform between R1.1 and R2 (once it is available), but this is highly desired.
• Gregg Seppala asked if a current DSTU could reference R2 datatypes. The group did not have an answer to this. The R2 migration is an important issue that needs to be addressed at the next WGM (if not sooner).
• Will be putting an FAQ on the wiki to help people understand why the XML ITS looks like it does.

Tooling Lloyd

• Continuing to work with the Open Health Tooling effort. There is an Eclipse version of the static model designer. Anyone interested in testing this should contact Lloyd. The first release will not be sufficient for replacing Visio, but the second release should be. HL7 has (at least verbally) committed to provide some funding for the second release.
• Infoway (a.k.a. Lloyd) will release a tool that help copy annotations from some DMIMs to RMIMs.
• Work progresses on the current V3 generator.

MnM Lloyd

• See Lloyd's slides.
• Woody presented the issue around negationInd.
• Motion: (Lloyd/Patrick) Accept the negationInd harmonization proposal. (11:0:1)

Other Items

• In Orlando:
  • Wednesday Q1 and Q2 will be joint with Vocab.
  • Wednesday Q3 & Q3 will be devoted to the new behavioral model.

Friday, September 19, 2008, Q1

• Draft schedule for the Orlando WGM was created.

Friday, September 19, 2008, Q2

No committee meeting.