1 Sunday September 11 Q3
- 1.1 Attendees
- 1.2 Agenda
  - 1.2.1 Establish Agenda for WGM from Hot Topics and Other Items
2 Monday September 12 Q3
- 2.1 Attendees
- 2.2 Agenda
  - 2.2.1 Joint with Patient Care to Discuss Detailed Clinical Models (DCM)
3 Monday September 12 Q4
- 3.1 Attendees
- 3.2 Agenda Host Clinical Statement Work Group
  - 3.2.1 Discussion Notes
4 Tuesday September 13 Q1
- 4.1 Attendees
- 4.2 Agenda - *Resources for Healthcare (RFH) - Governance of artifacts & managing complexity
5 Tuesday September 13 Q2
- 5.1 Attendees
- 5.2 Agenda
6 Tuesday September 13 Q3
- 6.1 Attendees
- 6.2 Agenda
7 Tuesday September 13 Q4
- 7.1 Attendees
- 7.2 Agenda
8 Wednesday September 14 Q1
- 8.1 Attendees
- 8.2 Agenda
9 Wednesday September 14 Q3
- 9.1 Attendees
- 9.2 Agenda
10 Thursday September 15 Q2
- 10.1 Attendees
- 10.2 Agenda
11 Thursday September 15 Q5
- 11.1 Attendees
- 11.2 Agenda
12 Friday September 16 Q1
- 12.1 Attendees
- 12.2 Agenda
  - 12.2.1 Adjournment

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

Briefly jumped to the preliminary definitional documents for RFH. (Core documents for RFH are available here.)

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:

Will be critical to be able to fold such extensions into a future release of a resource, because resources that cannot evolve are too rigid.
Will also need to deal with issues for retiring resources.
Discussion begs the question of whether there should be provision "Stakeholder-namespace extension code" in addition to an "HL7-namespace extension code"
Agreed
- 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 we will refactor and reissue the ontology.
How to we manage the resource space (boundaries between resources) -
- 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