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

Difference between revisions of "Conformance Weekly Meeting 2017 06 19"

From HL7Wiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 29: Line 29:
 
*Craig Newman
 
*Craig Newman
 
*Trevor
 
*Trevor
*Frank
+
*Frank Oemig
*Rob
+
*Rob Snelick
 
*John Roberts
 
*John Roberts
  
Line 36: Line 36:
 
*PHER Invite: Thursday, June 29. Discussions about implementing backwards compatibility. Conformance is invited to join.  
 
*PHER Invite: Thursday, June 29. Discussions about implementing backwards compatibility. Conformance is invited to join.  
 
**Discussion is being continued from last time.  
 
**Discussion is being continued from last time.  
**
+
*Update on project proposed by Templates
 +
**Waiting for PSS that Kai may have already started.
 +
**Conformance to join Templates at 2pm Central meeting
 +
*Birth and Fetal Death Reporting question
 +
**Curly braces are an annotation {1} or just a 1 is fine in UCUM. Anything inside a curly brace should not have a semantic meaning.
 +
**Still up-in-the-air on what you should do, many different options available. PHER couldn't come up with a standard.
 +
**Craig can get some examples from Immunization
 +
*Requiring all occurrences within a data type - question from PHER brought by Craig Newman
 +
**V2 field allows multiple occurrences and there is a type that classifies it, and it has multiple required values (e.g. address might have physical and mailing)
 +
**Overall consensus is, if the sender knows it then it should be sent if a required-to-support code, that seems to be a sensible answer
 +
**But not sure if this is enforceable this is given the current state of how things are written
 +
**Would like to see more formalism in this area
 +
**Discussed footnote on Page 17 of HL7 v2.8.2 Chapter 2B that tries to refine the definition of RE. There are issues with the definition.
 +
***The conflicting definition should really be defined by a different profile
 +
***Created from conversation 6 years ago
 +
**Take away: when writing 2+ chapter, need to very explicit on the expectations are for these requirements. Need to look at value sets and how they interact with field usage.
 +
***Local guides need to explicitly document their expectations. This is a stop-gap for now.
 +
***Conformance leans towards reporting all, but it should be documented so it's clear.
 +
*Approve WGM
 +
**Rob needs to review again
 +
*Data Types
 +
**Need to make sure the data types are named to not conflict with current data-types
 +
**Need to discuss data type names across versions that serve the same purpose
 +
**Will discuss this more on the next call

Latest revision as of 15:02, 19 June 2017

Meeting Information

  • Date: Monday, June 19, 2016
  • Time: 10:00 am, North America Eastern Time (New York, GMT-04:00)
  • Phone Number: +1 770-657-9270
  • Pass Code: 644843
  • Web Meeting: Uber Conference

Proposed Agenda Topics

  • Request from Templates for new Project
    • Update from John Roberts
  • Birth and Fetal Death Reporting IG: Two conformance questions raised by Mead Walker on listserv (Mead Walker)
    • Follow-up by Rob Snelick on research into OBX-6
  • Requiring all occurrences within a data type (Craig Newman)
  • Review and approve WGM minutes
  • Cochair Election
  • Data Types Project
    • Any updates?
  • Review FHIR Resource QA Tracker
  • FHIR Conformance Review

Attendees

  • Nathan Bunker
  • Craig Newman
  • Trevor
  • Frank Oemig
  • Rob Snelick
  • John Roberts

Discussion

  • PHER Invite: Thursday, June 29. Discussions about implementing backwards compatibility. Conformance is invited to join.
    • Discussion is being continued from last time.
  • Update on project proposed by Templates
    • Waiting for PSS that Kai may have already started.
    • Conformance to join Templates at 2pm Central meeting
  • Birth and Fetal Death Reporting question
    • Curly braces are an annotation {1} or just a 1 is fine in UCUM. Anything inside a curly brace should not have a semantic meaning.
    • Still up-in-the-air on what you should do, many different options available. PHER couldn't come up with a standard.
    • Craig can get some examples from Immunization
  • Requiring all occurrences within a data type - question from PHER brought by Craig Newman
    • V2 field allows multiple occurrences and there is a type that classifies it, and it has multiple required values (e.g. address might have physical and mailing)
    • Overall consensus is, if the sender knows it then it should be sent if a required-to-support code, that seems to be a sensible answer
    • But not sure if this is enforceable this is given the current state of how things are written
    • Would like to see more formalism in this area
    • Discussed footnote on Page 17 of HL7 v2.8.2 Chapter 2B that tries to refine the definition of RE. There are issues with the definition.
      • The conflicting definition should really be defined by a different profile
      • Created from conversation 6 years ago
    • Take away: when writing 2+ chapter, need to very explicit on the expectations are for these requirements. Need to look at value sets and how they interact with field usage.
      • Local guides need to explicitly document their expectations. This is a stop-gap for now.
      • Conformance leans towards reporting all, but it should be documented so it's clear.
  • Approve WGM
    • Rob needs to review again
  • Data Types
    • Need to make sure the data types are named to not conflict with current data-types
    • Need to discuss data type names across versions that serve the same purpose
    • Will discuss this more on the next call