MnM Minutes WGM 201109 San Diego

Sunday September 11 Q3

Attendees

Lloyd McKenzie (chair), Grahame Grieve, Alexander Henket, Sarah Gaunt, Steven Royce, Andy Stechishin, Woody Beeler, Jean Duteau, Hugh Glover, Patrick Lloyd, Russ Hamm, Austin Kreisler

Agenda

Establish Agenda for WGM from Hot Topics and Other Items

Steps:

• Reviewed the existing Hot Topics
  • Determined which would be considered

Decisions:

Motion: MnM believes there should be a project for RFH exploration and refinement (including impacts on existing methodology) and wishes to be sponsor or co-sponsor of such a project.

Woody/Andy 10/0/0

Motion: Approve Agenda for week

Andy/Patrick 10/0/0

Monday September 12 Q3

Attendees

Lloyd McKenzie (chair), Sarah Gaunt, Steven Royce, Stephen Chu, Woody Beeler, Andrew McIntyre, William Goosen, Kevin Coonan

Agenda

Joint with Patient Care to Discuss Detailed Clinical Models (DCM)

Discussion Opened by Dr. Goosen and ultimately centered on the "granularity" of a DCM and whether "clinical elements" are independent or not.

Patient Care concedes it is still seeking the appropriate path to represent and document their work.

Consideration of preparing SAIF Artifact Definitions to meet their needs was suggested, and they were encouraged to join that effort.

The challenge is how to accommodate the various conceptual models that groups seek.

Decisions:

Monday September 12 Q4

Attendees

Lloyd McKenzie (chair), Sarah Gaunt, Steven Royce, Rik Smithies, Woody Beeler, Rene Spronk, Ewout Kramer

Agenda Host Clinical Statement Work Group

Discussion Notes

Discussion was based on Wiki page Design Patterns for RIM Models

Clinical Statement - Is it Model vs Pattern? - Objective was as a model that would be constrained

Tools vs. Objectives - Current tools do not enforce any derivation (except the RIM). Does not provide traceability; detection of alignment vs difference;

Could/should portions of Clinical Statement become patterns that could be used to evaluate other models? More likely that sections of CS would be identified and then form the basis for a pattern.

What is pattern?

A "model fragment" (incomplete model) made up of "incomplete classes" -- incomplete implies that further extensions that are RIM-conformant can be used in the model whose content is based on the pattern.

Ergo, a Pattern is also a template.

NOTE: The class/clone names in a pattern are NOT required to be used in instantiating the pattern.

Design Pattern Meta-data

The pattern "Sections" of Design Patterns for RIM Models lists are the "Information Model Design Pattern Definition" one component of which is the model.

Agreements

Agreed to a formal name of "Information Model Design Pattern" for these and the Wiki page above needs to be edited to this end.

Agreed to build a Wiki Template for Design Pattern Definitions. LM will flesh out the sections and GB agreed to Wikify them.

Clinical Statement Work Group will undertake to consider elements of Clinical Statementthat can be proposed as Information Model Design patterns.

Tuesday September 13 Q1

Attendees

Grahame Grieve(Chair), Woody Beeler, Lloyd McKenzie, Sarah Gaunt, Austin Kreisler, Ann Wrightson, Corinne Gove, Adel Ghlamallah, Rob Hausam, Brian Pech, Peter Hendler, Rene Spronk, Ewout Kramer, Alexander Henket, Mark Tucker

Agenda - Resources for Healthcare (RFH) - Governance of artifacts & managing complexity

Grahame Grieve summarized the background of RFH (starting in MnM discussions in May 2011); its value propositions in regards to V2 and V3; the challenge of dealing with the complexity of our healthcare specifications. Primarily that the complexity should be tied to a super-rich ontology rather than describing it in detail in static models or V2 segments. Resulting in a collection of small "resources" information modules that can be communicated on there own, aggregated into records, but that provide a framework in which a simpler, smaller set of choices in constructing exchanges.

Briefly jumped to the preliminary definitional documents for RFH. (Core documents for RFH are available at http://www.healthintersections.com.au/rfh/introduction.htm.)

Highlighted the linkages of the elements to RIM (if required); features for extensibility to avoid the challenge of including everyone's edge case in a single universal model. In this circumstance the governance of

Discussion

Observation that the increasing complexity of issues of systems connections, bindings, etc. that lie beneath the health care content complexity are a bigger hurdle for implementations. Divergence of "local models" from "universal" models.

Governance

Expectations from Grieve:

• Work Group that manages the RFH Ontology and Methodology and delegates ontology space to other Work Groups
• Work Group that manages wire format issues
• Work Group that allocates Resources to Domain Work Group
• Work Group that manages extensibility, including the prompt issuance of extensibility codes, where required, after a proper definition has been provided.

Extensibility vs Evolution

Extensibility mechanism includes the ability to declare extensibility in the instance citing extension codes that have been defined and registered under HL7 Governance.

Observations and Modest consensus on questions

• Will be critical to be able to fold extensions into a future release of a resource, because resources that cannot evolve are too rigid.
• Discussion begs the question of whether there should be provision "Stakeholder-namespace extension code" in addition to an "HL7-namespace extension code"
• Will need to deal with issues for retiring resources.
• Agreed in re Extensions
  • There is need for some extensibility mechanism such as that cited
  • Need to be able to extend by defining your own concepts
  • Should define relationships between your and HL7 concepts, where exist
  • Be able to extend rapidly
  • Extensions need to be documented and collected
• Need to understand - early on - how will one refactor and reissue the ontology?.
• How does one manage the resource space (boundaries between resources), specifically -
  • Resource overlap
  • Inter-dependency
  • Scope (size)
  • Resources that are about single item but different level of detail
  • Differences by realm or practice scope
  • Needs to be STRONG consideration of the mechanism for grouping resources and whether these make it easier to consider how to deal with the important, but "different" realms
• How can resource definition management and maintenance be enabled and handled in multi-SDO environment.

Tuesday September 13 Q2

Attendees

Grahame Grieve(Chair), Woody Beeler, Lloyd McKenzie, Sarah Gaunt, Austin Kreisler, Ann Wrightson, Brian Pech, Peter Hendler, Ewout Kramer, Cecil Lynch, Jean Duteau, Gaby Jewell, Stephen Royce, Dale Nelson, Robert Worden, Alexander Henket, Mark Tucker

Agenda - Resources for Healthcare (RFH) - RIM in OWL and RIM Ontology

Overview by GG

• Exchange specification (XML formats)
• Ontology: Formal definition of the formats
  • Defines elements
  • Defines Reference models
  • Defines relationships between models and elements
  • Makes rules about
    • Kind of relationships that can exist and those that are required
    • What additional attributes relationship can have
  • Models
    • Reference
    • Design Patterns,
    • Domain glossaries

(Above from Grieve's slides, but is incomplete.)

Can we manage this as an Ontology?

• We believe we can embody the concepts and elements we need in an ontology
• Need to define an HL7 Reference Ontology that HL7 manages and defines the conformance to the element it defined.

OWL as Candidate Ontology Discussion

• Closed world only statements in my ontology are true
• Open world, anything not explicitly negated may be true
• LM: Cannot permit extensions to the RIM and remain conformant
• SG: Looked (in past) at how to represent models in ontology. At first rejected OWL because could not constrain in it, but later questioned decision. Should be possible to add albeit with ability of any user to recognize the "outside" extensions and skip them.
• GG: Can we make our own rules and test them - that is a key requirement
• LM: Four levels: base definition, extensions, local ontology defined against core, other stuff. Notion is that these should be considered in conformance rules, "other stuff" may be uglyu and non-conformant, but it will exist.
• CL: OWL weaknesses
  • In "open world" - If I say cardinality is and must be "2", OWL will allow a cardinality of "1" because it assumes the second is "coming"
• PH: Asserts that if an Act is defined, and someone adds an attribute, all prior Acts are no longer Acts. (I am confused).
• SG: In OWL, the rules do not come from the model, they come from OWL
• GG: Question posed was can it be done in OWL? Believes answer is yes, but it is not manageable. Discussion has exposed complexity that has nothing to do with the problem we are trying to solve.
• RW: Unsure what the question is is
• MT: Actually the changed Act becomes a sub-type, it does not change Act. Is the OWL complexity actually part of the 10% that we are trying to avoid.
• CL: What's missing - make statements that are illogical in RIM and vocabulary that ??? Perhaps we just need RDF and not all of OWL (?). Believes that rules engines are a reasonable consideration along with OWL.
• LM: Does not believe we are trying to "fix" the RIM, rather trying to find a more effective way to define and use elements defined against it.
• GG: In answer to RW - wants and ontology layer to (see Requirements on Ontology below
• WB: In regards MT comment that OWL complexity is the 10% on the 90-10 solution: problem is that it goes to the question of manageability of extensibility which is the central method for allowing one to ignore the 10%
• AW: Complexity we get into will depend upon the degree of control we believe we need to have. Fear that the more open one gets is when we will see increase in complexity.
• RW: In re: LM. statement. Clarified.
• GG: Rules are PRIMARILY intended to control US and make it clear that we are following our principles
• PH: Argues for subset of OWL to address the problem, except that a new relationship to an existing class negates all prior instances of that class.
• CL: Believes there is a very steep learning curve to using OWL for this end (and more difficult then SNOMED).
• GG: It cannot be arcane to add simple extensions, given requirements. Certainly the core setup will be complex and arcane.
• AK: The whole needs to be more accessible, not less accessible to people.
• PH: If we reduce it, its no different than SNOMED. Why don't we just try it.
• WB: If its no different but raises as much angst as we've heard, why start on it. AND we do not have the bandwidth to "just try it" while we are already just trying RFH.

Requirements on Ontology

• Use concepts as a basis for Reasoning
• Define concepts
• With rich text definitions
• Relationships between concepts
• Make rules about relationships
• Define content modularly (distributed development)
• Define concepts externally and then bring them in
• Based on a standard
• Must not need a PhD to implement this stuff or request extensions

AW: Should we not revisit what we have and apply the RFH principles to what we have.

GG: Thank all for participating. The majority of the complexity we have talked about is about OWL and suggests perhaps the tool is overqualified for the problem.

(WB: I did my best on these minutes. If I miss-summarized you, it was through my ignorance and not intentional.)

Tuesday September 13 Q3

Attendees

<<<NOT EDITED YET>>Lloyd McKenzie (chair), Sarah Gaunt, Steven Royce, Stephen Chu, Woody Beeler, Andrew McIntyre, Willem Goosen, Kevin Coonan

Agenda

• Joint with Structured documents - SAIF & CDA R3

Tuesday September 13 Q4

Attendees

Lloyd McKenzie, Woody Beeler (chair), Adel Ghlamallah, Karynk Harris, Andy Stechishin, Stephen Royse

Agenda

• Static Model Quality Checklist

Results

• Woody provided history and background on the Static Model checklist
• Checklist categories
  • Patterns
    • Add reference link to Use Id pattern
    • Add reference to Act.text Usage notes in RIM
    • Issue Usage notes in RIM document is an open issue
    • First Context Conduction stays
    • The ContetConductionStyle for the model MUST be 'V'and if one or both of the ActRelationship"blockedConduction...." attributes is present it must be mandatory and have a fixed value (set orf values) assigned.
  • General
    • Review the Metadata for the design with V3 Publishing
  • Vocabulary Constraints
    • Generic concepts can be automatically detect but needs to be assessed for validity
    • Concept domain specified for code needs to be assessed by human
    • Tooling issue: coding strength should only be specified for model bindings not for domain bindings or fixed codes.
  • Attribute Constraints
    • Added to wiki page
  • Descriptions
    • No changes

Motion: Endorse the changes made to the checklist and authorize Publishing to proceed to implement tests where possible (Lloyd, Andy) 5-0-0

Wednesday September 14 Q1

Attendees

<<<NOT EDITED YET>>Lloyd McKenzie (chair), Sarah Gaunt, Steven Royce, Stephen Chu, Woody Beeler, Andrew McIntyre, Willem Goosen, Kevin Coonan

Agenda

• Host Vocabulary: Publishing a value set in DEF or CRIT mood

Wednesday September 14 Q3

Attendees

<<<NOT EDITED YET>>Lloyd McKenzie (chair), Sarah Gaunt, Steven Royce, Stephen Chu, Woody Beeler, Andrew McIntyre, Willem Goosen, Kevin Coonan

Agenda

• Join Joint OO - Dynamic model artifact definitions

Thursday September 15 Q2

Attendees

<<<NOT EDITED YET>>Lloyd McKenzie (chair), Sarah Gaunt, Steven Royce, Stephen Chu, Woody Beeler, Andrew McIntyre, Willem Goosen, Kevin Coonan

Agenda

• SAIF Artifact Definitions & governance

Thursday September 15 Q5

Attendees

<<<NOT EDITED YET>>Lloyd McKenzie (chair), Sarah Gaunt, Steven Royce, Stephen Chu, Woody Beeler, Andrew McIntyre, Willem Goosen, Kevin Coonan

Agenda

• Facilitators Roundtable

Friday September 16 Q1

Attendees

<<<NOT EDITED YET>>Lloyd McKenzie (chair), Grahame Grieve, Alexander Henket, Sarah Gaunt, Steven Royce, Andy Stechishin, Woody Beeler, Jean Duteau, Hugh Glover, Patrick Lloyd, Russ Hamm, Austin Kreisler

Agenda

• ParameterItem.semanticsText
• ActRelationshipType cleanup