This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "MnM Minutes WGM 201305 Atlanta"

From HL7Wiki
Jump to navigation Jump to search
Line 137: Line 137:
  
 
==Methodology Issues that Came out of QA Assessment of FHIR==
 
==Methodology Issues that Came out of QA Assessment of FHIR==
==Distinction between "Type" and "Code" and Other field names==
+
===Distinction between "Type" and "Code" and Other field names===
 
Rationale for discussion: "type" and "code" have been used as attribute names for what is likely to be an encoded result.   
 
Rationale for discussion: "type" and "code" have been used as attribute names for what is likely to be an encoded result.   
  
Line 146: Line 146:
  
  
==Usage of Terms like "Subject", "Author" ==
+
===Usage of Terms like "Subject", "Author" ===
 
There were notes about inconsistencies of use of these terms.  Discussion here suggests that:
 
There were notes about inconsistencies of use of these terms.  Discussion here suggests that:
 
#Whatever definition for a term like "author" (for example) that FHIR selects should be consistent throughout FHIR
 
#Whatever definition for a term like "author" (for example) that FHIR selects should be consistent throughout FHIR
Line 156: Line 156:
 
Also the uniqueness criteria for names should be case agnostic.  Thus "LastMan" and "lastMan" are not unique.
 
Also the uniqueness criteria for names should be case agnostic.  Thus "LastMan" and "lastMan" are not unique.
  
==Discussed McKenzie Discussion of "Subject"==
+
===Discussed McKenzie Discussion of "Subject"===
 
Appears focused on context conduction and the need to clearly state what if ANY assumptions can be made thereabout.
 
Appears focused on context conduction and the need to clearly state what if ANY assumptions can be made thereabout.
 
What if a contained object has no subject??  
 
What if a contained object has no subject??  
Line 162: Line 162:
 
Discussion recognized that FHIR's light-weight reference mechanism makes it reasonable to represent the subject in (for example) each member of a battery of tests.
 
Discussion recognized that FHIR's light-weight reference mechanism makes it reasonable to represent the subject in (for example) each member of a battery of tests.
  
===Subsequent Summary by E. Kramer on this discussion and the topic above it===
+
====Subsequent Summary by E. Kramer on this discussion and the topic above it====
 
:What the notes don't reflect is that there was no clear consensus about the use of subject/author etc. Most agreed that it was not necessarily a good idea to use them everywhere, because e.g. Order.subject is ambiguous.  
 
:What the notes don't reflect is that there was no clear consensus about the use of subject/author etc. Most agreed that it was not necessarily a good idea to use them everywhere, because e.g. Order.subject is ambiguous.  
 
:There was concern that because of the v2/v3 background, users of the spec would assume they understood what "subject" and "author" means, though in FHIR the meaning of that word may change from resource to resource.  
 
:There was concern that because of the v2/v3 background, users of the spec would assume they understood what "subject" and "author" means, though in FHIR the meaning of that word may change from resource to resource.  
 
:So, the consensus was that it should be used consistent across all resources if it is used on occasion, but that it is not necessarily a good idea to try to use these terms in all resources.
 
:So, the consensus was that it should be used consistent across all resources if it is used on occasion, but that it is not necessarily a good idea to try to use these terms in all resources.
  
==Discssion of mustUnderstand on optional Booleans==
+
===Discssion of mustUnderstand on optional Booleans===
 
The line item 6 from McKenzie, is moot if all mustUnderstand have minimum cardinality of 1, which is currently on the "warning" track for becoming a rule.
 
The line item 6 from McKenzie, is moot if all mustUnderstand have minimum cardinality of 1, which is currently on the "warning" track for becoming a rule.
  

Revision as of 16:19, 8 May 2013

Return to MnM Minutes for 2013

Contents

Sunday May 5 Q3

Agenda

  • Hot topic triage
  • Agenda planning

Attendees

Beeler Jr, George (Woody) (Beeler Consulting LLC)
Grieve, Grahame (Health Intersections Pty Ltd)
Hay, David (HL7 New Zealand)
Kramer, Ewout (Furore)
Loyd, Patrick (ICode Solutions)
McKenzie, Lloyd (HL7 Canada)
Shakir, AbdulMalik (City of Hope National Medical Center)
Stechishin, Andy (CANA Software & Services Ltd.)
Walker, D. Mead (Mead Walker Consulting)

Hot topics

1. RIM ballot reconciliation - Fixed values for collections of repeating attributes - What's the RIM default - How do we make it work in the schema generator

2. Lloyd will close the "social media" hot topic

3. Discussed "Model to Template Relationship", but no need to bring it up as a hot topic

4. Data types vocabulary schemas - what are we allowed to do within the framework of the ISO spec

5. FHIR RIM mappings - What will RIM mapping look like? - What do we do when the RIM can't do it? - What will it achieve?

Will tackle #1 and #4 in this meeting, #5 slotted for joint FHIR/MnM discussion For Wed Q3, will host FHIR (will release room 219)

Release rooms for Tue Q1, Tue Q4

Move SAIF Artifact Definition Project from Tuesday Q4 to Thursday Q2

Motion: approve agenda for WGM - Woody/Patrick

RIM ballot reconciliation

Two Negatives from Dale Nelson

Findings documented in Reconciliation spread sheet. Vote: Not persuasive 7-0-1 (Woody/Grahame)

Beeler's Negative regarding blocked context conduction attributes

Steps to resolve:

  • We should create value sets containing conductable ActRelationship type codes
  • Designers can create a new value set that constrains the base value sets as per the rules in Core principles
  • Designers can create a fixed value that is a "list of codes" that draws from the codes in the value set
  • Tooling needs to verify this will propagate properly through the tools to the schemas
  • MnM will document this in Core principles

Motion on these steps: Woody/Grahame 5-0-0

Woody takes action item to update Core Principles

Based on the above, Woody withdraws his negatives

Data type vocabulary schemas

Discussed issues that arise from mismatch of vocabulary terms listed in Data Types Specifications; those assembled into vocabulary schema; and those in Vocabulary content. Agreed on a strategy for isolating these and correcting them. Beeler will work with Grieve to accomplish this.

Monday May 6 Q1

Agenda

Chair - Beeler & Grieve

  • FHIR Methodology

Attendees

Abrahao, Marivan (HL7 Brazil)
Beeler Jr, George (Woody) (Beeler Consulting LLC)
Cabrita, Rolim (Interfaceware)
Duteau, Jean (Duteau Design Inc)
Fine, Steven (Cerner Corporation)
Glinski, Steve (Surescripts)
Grieve, Grahame (Health Intersections Pty Ltd)
Henderson, Mike (Eastern Informatics, Inc.)
Jewell, Gabriele (Cerner Corporation)
Konishi, Yukinori (HL7 Japan)
Liu, Andrew (HL7 Canada)
Lynch, Cecil (Accenture)
Moehrke, John (GE Healthcare)
Parker, Ron (HL7 Canada)
Ryal, Tod (Cerner Corporation)
Shaver, Dave (Corepoint Health)
Smithies, Rik (HL7 UK)
Takasaka, Sadamu (HL7 Japan)
Walker, D. Mead (Mead Walker Consulting)
Wong, Nat (HL7 Australia)
Worden, Robert (Open Mapping Software)
Kavanagh, Richard (NHS England)
Walia, Randeep (Grafight Scratch, Inc.)
Murty, Kurella (Roche)

Topic: mustUnderstand

Discussion of mustUnderstand - Motion from G Grieve/Rik Smithies to "Rename mustUnderstand to isModifier, and add sentence saying that you must explain why it is that you think it is a modifier and/or what it modifies."

Approved 25-0-0

Topic: Various

Discussions around "messaging-like" paradigm with FHUR similar to V2, can be defined and has been tested.

Discussions on "Profile" resource and what is does. Is rather larger than desired. Was noted that although it is defined as a Resource, it is unlikely to be exchanged as instances.

Security and FHIR

There is a Wiki document in the "FHIR Publication" that is being built with the guidance of Security Work Group lists security-related issues when using FHIR, and how and where these might be addressed.

Monday May 6 Q2

Ewout Kramer and Woody Beeler for FHIR and MnM

Agenda

  • Host FHIR
  • FHIR Methodology

Attendees

Beeler Jr, George (Woody) (Beeler Consulting LLC)
Brancato, Chris
Cheung, James (Kaiser Permanente)
Fine, Steven (Cerner Corporation)
Greim MS RN-C, Patricia (U.S. Department of Veterans Affairs)
Jewell, Gabriele (Cerner Corporation)
Kavanagh, Richard (NHS England)
Kramer, Ewout (Furore)
Liu, Andrew (HL7 Canada)
Lynch, Cecil (Accenture)
Moehrke, John (GE Healthcare)
Ott, Russell
Parker, Craig (Intermountain Healthcare)
Pupo, Erik (Deloitte Consulting LLP)
Ryal, Tod (Cerner Corporation)
Shaver, Dave (Corepoint Health)
Smithies, Rik (HL7 UK)
Walia, Randeep (Grafight Scratch, Inc.)
Walker, D. Mead (Mead Walker Consulting)
Wong, Nat (HL7 Australia)

Methodology Issues that Came out of QA Assessment of FHIR

Distinction between "Type" and "Code" and Other field names

Rationale for discussion: "type" and "code" have been used as attribute names for what is likely to be an encoded result.

Discussion suggests that: "code" commonly adds NO understanding; should not repeat name of element in attribute; type works where it is the type of the element; code is not useful; if need further distinction and expand "type"

Similarly, "date" as an attribute name will beg the distinction of which kind of "date" (e.g. see V3 Act) is intended.


Usage of Terms like "Subject", "Author"

There were notes about inconsistencies of use of these terms. Discussion here suggests that:

  1. Whatever definition for a term like "author" (for example) that FHIR selects should be consistent throughout FHIR
  2. A Glossary would be very difficult (these tend to be more fine-grained than the usual glossary)
  3. The RIM vocabulary (participation type codes, for example) provide fairly carefully thought out (and reviewed) set of definitions for things like "author", etc.

Suggest that FHIR consider adopting upper and lower camel case for names - lower for parameters and attributes, upper for resources and elements; etc.

Also the uniqueness criteria for names should be case agnostic. Thus "LastMan" and "lastMan" are not unique.

Discussed McKenzie Discussion of "Subject"

Appears focused on context conduction and the need to clearly state what if ANY assumptions can be made thereabout. What if a contained object has no subject??

Discussion recognized that FHIR's light-weight reference mechanism makes it reasonable to represent the subject in (for example) each member of a battery of tests.

Subsequent Summary by E. Kramer on this discussion and the topic above it

What the notes don't reflect is that there was no clear consensus about the use of subject/author etc. Most agreed that it was not necessarily a good idea to use them everywhere, because e.g. Order.subject is ambiguous.
There was concern that because of the v2/v3 background, users of the spec would assume they understood what "subject" and "author" means, though in FHIR the meaning of that word may change from resource to resource.
So, the consensus was that it should be used consistent across all resources if it is used on occasion, but that it is not necessarily a good idea to try to use these terms in all resources.

Discssion of mustUnderstand on optional Booleans

The line item 6 from McKenzie, is moot if all mustUnderstand have minimum cardinality of 1, which is currently on the "warning" track for becoming a rule.

Monday May 6 Q3 and Q4

Agenda

  • Join Joint w/FHIR, ITS
  • FHIR Infrastructure issues

Minutes by ITS

Tuesday May 7 Q2

Agenda

  • "Ask MnM"

Attendees

Beeler Jr, George (Woody) (Beeler Consulting LLC)
Luensman, Genny
Shakir, AbdulMalik (City of Hope National Medical Center)

Occupational Data for Health

Discussed how to assure that appropriate data about patient's occupations and occupation history are captured and retrievable within electronic health records. Started with a data model (entity-relationship diagram) titled "Occupational Data for Health" from Genny Luensman of CDC/NIOSH/DRDS/SB.

While the model is readily representable in RIM semantics, the core question is how to assure these data are considered in profiles being on Consolidated CDA for consideration in Meaningful Use. The discussion was useful, the proponents are currently engaged with projects providing data requirements for meaningful use and therefore, at this point, do not need further help with regards to RIM and or methodology.

Tuesday May 7 Q3

Joint w/ Structure Documents (refer to their minutes)


Wednesday May 8 Q1

Agenda

  • Host Vocab

Attendees

Beeler Jr, George (Woody) (Beeler Consulting LLC)
Case, James (National Library of Medicine)
Couderc, Carmela (Siemens Healthcare)
Hamm, Russell
Hausam, Robert (Hausam Consulting)
Huang, Wendy (Canada Health Infoway Inc.)
Klein, William Ted (Klein Consulting, Inc.)
Liu, Andrew (HL7 Canada)
McKenzie, Lloyd (HL7 Canada)

Representation of Human Language ConceptDomain

Problem is that the ConceptDomain HumanLanguage is bound in the RIM and data types. The Data Types binding causes a Universal binding to a ValueSet (from the ConceptDomain referenced in Abstract Data Types). There is a need presented to have the data type for RIM languageCode be CD (or CE) which would require a different binding.

Recognize that a different Concept Domain could be used for the RIM binding of languageCode in RIM, that then might be used for a different binding in a realm.

Challenge is that we are seeking to relax a ling-standing binding that is usable, except that the proposal seeks to use only 3-character codes that is counter to the IETF requirement that communication use the 2-character whenever a single concept is represented by both a 2-character and 3-character code.

Alternate concern is that we are taking a CD data type and forcing all realms to use a single binding. Note that this is the ONLY RIM attribute of type CD that is universally bound, as a result of the happenstance of the same concept domain being used in Abstract Data Types.

Resolution

Motion made by Huang, seconded by Klein that a harmonization proposal be prepared to:

Create a new Concept Domain be used as the RIM constraint on attribute LanguageCommunication.languageCode, including a definition of that concept domain; and to create a Representative Binding for that Concept Domain that matches the existing universal binding on Concept Domain HumanLanguage.

Approved - 7 Aye- 1 Against -0 Abstain

Core Principles Release 3 Content

Note that Core Principles R2 has not completed reconciliation. Nevertheless, given methodology and ISO changes, it is worthwhile developing a list of items for future inclusion in Core Principles, including:

  • Binding Intensity - already agrred to by Vocabulary & MnM
  • Need to better document how to express (in designs) and constrain the codes for the "blockedContextConduction..." attributes, including how they appear in schema
  • Clarify what happens when a MIN ValueSet is not provided in a binding
  • Management of text between Glossary and Body of document, which is currently confusing

Wednesday May 8 Q2

Agenda

  • Host Vocab, FHIR
  • FHIR Vocabulary

Attendees

Beeler Jr, George (Woody) (Beeler Consulting LLC)
Canu, Nicolas (HL7 France, L'Atelier du Soft)
Couderc, Carmela (Siemens Healthcare)
Estelrich, Ana (Phast)
Hamm, Russell
Hausam, Robert (Hausam Consulting)
Hirai, Masaaki (HL7 Japan Voter #2 - Nihon Kohden Corp, Eng. Oper.)
Huang, Wendy (Canada Health Infoway Inc.)
Huff, Stanley (Intermountain Healthcare)
Jewell, Gabriele (Cerner Corporation)
Klein, William Ted (Klein Consulting, Inc.)
Konishi, Yukinori (HL7 Japan)
Liu, Andrew (HL7 Canada)
Lyle, Jay (Ockham Information Services LLC)
McClure, Robert
McKenzie, Lloyd (HL7 Canada)
Ott, Russell
Parker, Ron (HL7 Canada)
Snelick, Robert (National Institute of Standards and Technology)
Stuart, Sandra (Kaiser Permanente)
Takasaka, Sadamu (HL7 Japan)

FHIR Vocabulary-related "QA" Issues

FHIR has a "QA" review list that it is working through in preparing the DSTU. Several of these are vocabulary-related and were discussed here. Agreements/results from this meeting were documented in the FHIR QA pages.

FHIR Review of Value Sets

Agreed that there should be a formal review process established to review the value sets being authored as part of FHIR resource development process, in order to be prepared for dealing with Negative comments on the DTSU ballots of FHIR being prepared for the upcoming ballot cycle.

Agreed to following (loosely defined) process

  1. Will establish a pool of volunteer reviewers. Seek volunteers to do the reviewing
  2. Individuals wil review designated portions of the list of Value Sets (chunks) to make recommendations to the FHIR developers, with an independent review by a second volunteer.
  3. FHIR Management Group will assign each Value set to two of volunteeers in chunks, with report on each chunk expected back in a week
  4. Will be two classes of review
    1. Where not have code lists looking for volunteers who might identify external source
    2. Where do have a code list, review for consistency and possible substitution from external source
  5. All recommendations will be managed and tracked by FMG
  6. FMG will escalate tougher issues to Vocabulary call

Wednesday May 8 Q3

Agenda

  • Host FHIR
  • FHIR Core

Attendees

Topic 1

Thursday May 9 Q1

Agenda

  • FHIR Methodology

Attendees

Topic 1

Thursday May 9 Q2

Agenda

  • SAIF Artifact Definition

Attendees

Topic 1

Thursday May 9 Q5-Q6

Agenda

  • MnM Roundtable

Attendees

Topic 1

Thursday May 9 Q2

Agenda

  • SAIF Artifact Definition

Attendees

Topic 1

Friday May 10 Q2

Agenda

  • Meeting planning

Attendees

Topic 1