MnM Minutes WGM 201105 Orlando

Sunday May 15 Q3

Attendees

Lloyd McKenzie (chair), Susan Campbell, Grahame Grieve, Stephen Chu, Brian Pech, Sarah Gaunt, Lorraine Constable, Amnon Shabo, Larry Reis, Bruce McKinnon, Andy Stechishin, Woody Beeler, Jean Duteau

Agenda

Establish Agenda for WGM from Hot Topics and Other Items

Steps:

• Reviewed the existing Hot Topics
  • Determined which would be considered in Orlando
• Added a quarter for ballot reconcilliation
• Added a quarter for MnM Business (Co-chairs, SWOT, Project Review, etc.)

Decisions:

• Mon Q1 - RIM/Core Principles Reconciliation
• Mon Q2 - SAIF Artifact Definition Discussion
• Mon Q3 - DCM Pilot Project discussion with Patient Care
• Mon Q4 - Joint with SD - discuss non-conformance of "Don't Ignore"
• Tue Q1 - Design Pattern Process
• Tue Q3 - hData discussion with ArB
• Tue Q4 - MnM Business
• Wed Q1 - Joint with Vocabulary
• Fri Q1 - ActRelationshipType cleanup discussion

Monday May 16 Q1

Attendees

Lloyd McKenzie (chair), Woody Beeler, Lee Coller, John McKim, Stacy Berger, Jean Duteau

Agenda

RIM Reconciliation

• Agreed with all proposed resolutions. Motions and resolutions are noted in the ballot spreadsheet.
• Kevin Coonan's comments were received after the deadline and three of them require harmonization proposals. Hot Topics will be created for them.

Core Principles Reconciliation

• Microsoft's comments were a resubmissions of comments from the September 2010 ballot. All of those comments were dealt with in a previous reconciliation and were found to be Not Related.
• All other comments were dealt with. Motions and resolutions are noted in the ballot spreadsheet.

Tuesday May 17 Q1

Agenda

=== Design Pattern Process

Tuesday May 17 Q3

Attendees

Lloyd McKenzie, Bruce McKinnon, Stephen Royce, Andy Bond, Sarah Gaunt

Agenda

Business Session

Reviewed and updated

• Mission & Charter
• SWOT
• 3-year plan

Motions by Bruce M., second: Stephen R, unanymous

Tuesday May 17 Q4

Agenda

hData discussion

HDATA Discussion

• Consideration of hData model including examples
• Decisions:
  • hData to add some new and extensional metadata content
  • Grahame to draft three hData Content profiles:
    • CDA document section document Profile (undecomposed)
    • General RIM section document Profile
    • Version 2.0 messaging profile
  • Ann to add examplar for decomposed CDA
    • Along with clear description of control points that make this safe

Wednesday May 18 Q1 (Joint with Vocabulary)

Attendees

Woody Beeler (Beeler Consulting) woody@beelers.com Beverley Knight (Infoway) bknight@infoway.ca Brian Schwallier (Health Language) brian.schwallier@healthlanguage.com Tim Benson (Abies UK) tim.benson@abies.co.uk Lloyd Mckenzie (HL7 Canada) lloyd@mckenzie.com Carmela Couderc (Seimens) carmela.couderc@seimens.com Rob Savage (NGC/CDC) hzv3@cdc.gov Wendy Huang (Infoway) whuang@infoway.gov.au Jim Case (NLM/NIH) james.case@mail.nih.gov Ted Klein (KCI) ted@tklein.com Stephen Royce (NEHTA) stephen.royce@nehta.gov.au Grahame Grieve (Health Intersections) grahame@healthintersections.com.au Heather Grain (LG Informatics) heather@lginformatics.com.au

Agenda

• MIF ballot
• Information Model metadata documentation
• IHTSDO alignment (agreement + process + impacts)
• Harmonization - patterns
• Value set definitions in Acts in definition mood
• Registering Concept Domains from International Affiliates

MIF Ballot

• MIF will never end
• phase #1 is complete, submitted to TSC for publishing
• Work will start again, but no timeline

Information Model Metadata documentation

• Need to better describe model metadata
• Listed on the scope statement: Lloyd.
• Beverley to enhance the scope statement, and bring it forward for formal consideration
• a companion for core principles
• for people doing design

Harmonisation - design patterns

• Lloyd explained design patterns and their impact on harmonization, for vocabulary's information
• Vocabulary was aware of the relevance and potential impacts

Discussion of HL7 IHTSDO Process

• Harmonization impacts were discussed
• in order to have a HL7 namespace for snomed, we need a gatekeeper
  • A central authority with documentation of the processes (to ensure due diligence) + with contact details (we don't need that much detail of the process)
  • Much contention about the process - some of this was discussed; vocab still to make decisions
  • General agreement that we would like to move our processes and our current vocabulary content towards a more vigorous base
  • Agreement that this consideration impacts on our direction, but shouldn't slow us from taking immediate action
  • There may be a reason to consider splitting the HL7 namespace into multiple parts with different management processes
• The interests of HL7 - both short and long term - would be well served by enhancing the existing process with the goal of moving as much of the HL7 terminology as feasible and sensible into Snomed-CT (either the core or the HL7 extension)
• We still need to measure the costs of tightening up on the harmonization process and determine where (i.e. which terminologies) they should be imposed
• Woody volunteers to participate in the process going forward, and proposes a meeting during harmonization
• Possible: Add to snomed checklist a flag for "include in Snomed-CT core" (and also exclude)
• We proposed prototyping the process this harmonization as a trial balloon

OIDs and value sets in CDA implementation guides

• Issues with how to handle US realm specific implementation guides and value sets
• OIDs not governed by HL7 are clearly marked
• CDA implementation guide value sets need to be registered in the OID registry
• CDA value sets in MIF - not known whether or when that will happen

Concept domains from International Affiliates

• only one authority can define concept domains - HL7 Intl
• affiliates can request a concept domain through harmonisation (via domain committee or intl affiliates)
• challenge if the concept domain doesn't make sense in the relevant domain committees models
  • i.e. a concept domain represents constructs in lab that assumes a central repository; intl model doesn't support that and don't want to add it
• how to manage that circumstance in harmonisation?.
• Lloyd Proposes
  • if something comes to harmonization that is not aligned, WG can reject proposal, and affiliate must work to align
  • if that turns out not to be possible (committee does not want to adopt requirement in the model), bring it forward to harmonization where it will be accepted
  • domain must still be valid against all the other rules
  • affiliates should inform other affiliates
• General agreement.
  • nice if you could hide them if you don't want to see them
  • could have a property on the domain to tag it
• Lloyd to bring to round table and then to committees and affiliate council list

Adjournment

Adjourned at 10:35

Thursday May 19 Q6

Attendees

Woody Beeler (+ Selby), MnM Ted Klein, Vocab Rob Hausam, OO Michael Chung, PC Alexander Henket, PA Lorraine, Guest Patrick Loyd, CS + InM Amnon Shabo, CG Lloyd Mckenzie, MnM Grahame Grieve, MnM Rob Savage, PHER Andy Stechiscin, ITS Wendy Huang, PA + Pharmacy Kevin Coonan, PC + Emerg Bob Dolin, SD Gaye Dolin, SD + Child Health Hugh Glover, Pharmacy

Agenda

Next harmonization meeting July 12 - 15. On the agenda:

• for the next version of the RIM
• Harmonizing design patterns - a separate day

Facilitators' Roundtable

Ted (Vocab):

• CPP - 55 Negs, 5 done. Expect to go normative Summer
• CTS 2 - major release from OMG on Monday
• agreement with IHTSDO: progressing quickly
• Meeting with Anat Path: created a project to be able to distribute templates with included valuesets
• 2.8: overhaul to use CPP vocabculary structures in v2.

Hugh (Pharmacy):

• Procedural difficulties of publishing content - can we have internal publishing process? + other publishing issue
• Seeking to co-locate a meeting with IHE
• Considering implementation guides
• Now harmonizing content with Structured Documents

Rob:

• ongoing work in BF & v2.
• Microbiology template in next cycle
• will bring a document forward about effectiveTime to clarify it's usage

Michael:

• Main topic: care provision model

Alexander:

• Harmonize Encounter with Patient Care - and back to ballot
• Registries + interdependent registries (joint work with SOA)

Penny:

• for vocab - will have new concept domains to allow for context binding
• codes for blocking context conduction: syntax didn't work - to be investigated (but doesn't appear properly in Sydney)

Amnon

• Would like to use the SMD, but still not possible
• Will be balloting a gene expression CMET in the next cycle
• specimen is a big big issue

Grahame

• Announced Data Types R3 + ITS R2B outcome
• Discussed the Fresh Look task force Fresh Look

Andy

• ITS says "it's not our fault"
• CMETs are somewhat adrift (It's still not ITSs fault - it's Andy's)
• Dave is going to rescue the CMETs for ANSI approval
• There is a gForge project for CMET management - go there if you need new CMET identifiers

Kevin

• Going to redo DMIM and RMIM to update them
• Care provision is going to be a clinical statement
• design pattern for health concern in health records
• much future work planned with DCMs and the fresh look taskforce
• MnM needs to provide guidance about what makes a good DAM

Lloyd:

• Report on MnM's week

Friday May 20 Q1

Attendees

Lloyd McKenzie, Jean Duteau, Alexander Henket, Mark Janczewski, Kevin Coonan

Agenda

ActRelationshipType vocabulary cleanup

Issues

• Codes aren't necessarily well defined
• Codes don't clearly identify what's the source and what's the target
• Descendant codes don't necessarily have the same source-target direction as their anscestors
• Semantic characteristics such as transitivity, reflexivity, etc. aren't necessarily consistent between parent and child
• No clear rules (or way of enforcing the rules) around restrictions on classCode and/or moodCode for source and target acts
  • In some cases, may need rules that define the allowed relationship between source and target moods. E.g. source and target classCode need to be the same, or target must be specialization of source.
• Where such rules are stated, they're not necessarily valid/appropriate
• Sibling codes aren't necessarily mutually exclusive
• Some codes that should have parent/child relationships don't
• Some codes have questionable utility - e.g. PERT
• Not clear that all codes are really needed for use in models - some may exist to give desired names rather than essential semantics
• Some codes are missing definitions e.g. CURE, DIAG
• Names don't necessarily align with underlying semantics of the code
• Formal naming properties aren't necessarily populated, or populated correctly

Proposed Approach

1. Figure out what the "ideal" vocabulary hierarchy would be, complete with appropriate properties and definitions - don't worry about backward compatibility
2. Decide whether to deprecate existing code system and move to new code system (as we did with some code systems in DT R2) or to merely deprecate codes and define new ones
   1. If moving to a new code system, will need to differentiate between models using the "old" semantics vs. those using the new semantics if automatic update isn't possible/safe
3. Create tutorial that covers key design patterns & importance of selection of appropriate codes to help train modeling facilitators (and for use in QA processes)

Rules for "new" AR Type codes

1. Relationship name must make explicit the "source to target" semantics and clearly align with the definition for the code
2. Each relationship must identify the set of allowed source classCodes, source moodCodes, target classCodes, target moodCodes. (Set can be conveyed either by identifying ancestor code which will imply all children or by listing explicit codes when necessary)
3. Each relationship will have a code identifying the relationship between source and target classCodes (must be equal, source must be same as or specialize target, target must be same as or specialize source, no relationship required)
4. Each relationship will have a code identifying the relationship between source and target moodCodes (must be equal, source must be "more actual" than target, target must be "more actual" than source", no relationship required)
5. Each relationship will define the following relationship properties:
   1. transitivity (transitive, anti-transitive, neither)
   2. reflexivity (reflexive, irreflexive, neither)
   3. functionalism (functional, inverse-functional, both, neither)
   4. symmetry (symmetric, anti-symmetric, neither)
6. Ensure that a concept has relationship properties that align with the relationship properties of its parent concept(s)
   1. NOTE: Need to figure out what the rules are for such alignment
7. Where an ActRelationship is a "short-cut" for a more complex modelling pattern, the definition shall define (or at least reference that pattern)
8. Objective is to minimize the number of distinct relationship types
9. Must have a non-tautological definition that explicitly references source and target and clearly distinguishes the relationship type from sibling codes and parent code.
10. Validate that child code is fully aligned with and satisfies the "is a" relationship with its parent
11. Must declare values for formal naming properties and ensure that such names make obvious the "source" to "target" directionality
12. Must have at least one example of a code being used (appropriately) in a model to retain it in the hierarchy.
13. Ensure that modelling guidance is clear that if you pick an ancestor code for use in a model, *all* of the child codes must be potentially valid within that model.

Specific issues

• Do we want to separate "subject" and "qualifier"?
• Do we want to separate "component" and "aggregation"?
• Can we toast PERT?

Motion

Will proceed to refactor the ActRelationshipType vocabulary based on the above principles with an objective of having a revised hierarchy available for review by the Sept. WGM, to make a decision on implementation approach at that meeting. Moved: Kevin/Jean 3/0/0