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

Difference between revisions of "2015-c1-Inm current-info"

From HL7Wiki
Jump to navigation Jump to search
Line 22: Line 22:
 
#*** 2.A.58 PT - processing type  
 
#*** 2.A.58 PT - processing type  
 
#*** 2.14.9.11 MSH-11  Processing ID  (PT)  00011
 
#*** 2.14.9.11 MSH-11  Processing ID  (PT)  00011
 +
#* 191 Type of Referenced Data
 +
#**Values in the standard do not agree with the values in the database.  There are two different sets of values originating in version 2.3.1 listed in two places, with only partial overlap.    An additional error in the database seems related to the SGML code in version 2.3.1. 
 +
#**Review with WG and Frank to fix in database
 +
#**Ideal solution would be to set ‘Application’, ‘Image’, and ‘Audio’ as synonym codes to AP, IM, and AU, and set them to retired as of 2.4   
 +
#**FO: for v2.3.1 virtually deleted in #78                                                   
 +
#**'''Motion''' to approve setting ‘Application’, ‘Image’, and ‘Audio’ as synonym codes to AP, IM, and AU, and set them to retired as of 2.4. 
 +
#*207 Processing mode
 +
#**There is an entry "Not present" in all versions of the table; this needs to be removed and replaced with a field note on what the meaning of an unpopulated code value is.
 +
#**Ted sent email to Tony on this 12/7/15.
 +
#**Verified code is deprecated (status D) in db86.  Ted must clarify with INM that it is not to be simply removed with a note on the field.               
 +
#**'''Motion''' to deprecate "Not present" from the table and add a field note.               
 +
#* 254 Kind of Quantity
 +
#**Values from version 2.3 not appearing in the database.  Need to determine if the values are the same as v2.3.1; WG advice sought.  Note also that many print names include an asterisk for a footnote in the table commentary.  This should probably be changed to text in the Comment column of every table.  Advice sought from WG.
 +
#**Review with WG and Frank to fix in database 
 +
#**As of v77 2.3 values added back into database.  For all codes having printnames with an asterisk, remove the asterisk and add a comment “Adopted from the IUPAC Silver Book 1995” to the code                                                                                     
 +
#**Asterisks still in printnames in #78.  Ted to followup up with INM on putting the footnotes into the comment fields for the codes.                                                       
 +
#**FO: done in #79, do we need a comment instead?  Ted will follow up with INM  and OO on this.  As of db86, asterisks removed from print names but left in definitions.  As the footnote that the asterisk refers to is not part of the vocabulary, should something be done about that?  Such as putting the footnote text in the usage note column?  Or in the table description?  Discuss with INM and ask if having the footnote text in usage note is ok.       
 +
#**'''Motion''' to approve footnote text.                                                     
 +
#* 290 MIME base64 encoding characters
 +
#**the entry from the table for null values - (pad) = - was removed from the database.  INM must be asked what should the code system actually contain for this entry, and how it should be rendered (since it has been removed from the database, it will no longer show up in the chapter 2C enumeration of the table).
 +
#**INM must weigh in on what to do about this.
 +
#**still waiting on input from INM.  Note that this should probably NOT be an HL7 code system, but it is unclear of what kind of vocabulary object this reference table should be.  It has been removed from the 2C output for 2.9; is this correct?                                                             
 +
#*291 Subtype of referenced data
 +
#**as of v2.6, code system was deprecated, and a new value set recommended to be built on RFC2046 plus the HL7 CDA codes. Need to make this a user defined table?  Need to check the published MIME types to make sure the CDA subtype is represented in RFC 2064.  Need to clarify from INM whether the intent is to include all types from RFC 2064 or only the enumerated subset?  Note this is an HL7 table.  Are there any IP issues in republishing these values?   
 +
#**FO: unclear what to do here?  Ted will clarify and update the spreadsheet, after which Frank will apply the necessary changes.  Create an enumerated value set based on RFC2064 for this for 2.2 through 2.5.1, and just add the single CDA entry as an enumerated entry in the VSD; not clear what code system it should be drawn from, discuss with Tables project.         
 +
#**FO: unclear, need values; we currently work on the same stuff in a value set project for Germany (goal is to support XDS)  Ted will discuss with INM.
 +
#**Review with WG and Frank to fix in database.  In San Antonio meeting Russ assigned to square this away with INM in conjunction with 290 above.
 +
#**This code system went away as of 2.6; HL7 code system prior to that.  After 2.5.1, this is a value set built on RFC2064 all codes plus the one x-cda… code from the original old code system.  Update spreadsheet as this is a change to the decisions.  Excel sheet updated on 2/25 call.  All values removed or set to Deprecated in db86; what is the desire of INM for this output to be?   
 +
#**'''Motion'''                 
 +
#*338 Practitioner ID number type
 +
#**This table has nearly 100% overlap with the content of table 203; retire this code system in v2.9 and this table becomes a value set built on table 203 code system, and add the sole missing value (TRL) to 203, and get rid of the old deprecated L&I code completely.  The code system for this table goes away as of 2.9
 +
#**Seek confirmation from INM.  Seek advice on what, if anything to do about content in older HL7 v2.x; Frank to implement recommendations.
 +
#**INM ok with this, leave the older stuff as is.  TRL will be added to 203 in v2.9.    This table will be a value set built on 203, with the TRL code added for the older versions.  Value set must be enumerated.
 +
#**FO: we have to do the value set stuff later on, so we need to keep this issue for later  Note that the last harmonization meeting (March) had table 203 updates, but the code TRL was *NOT* added to table 203 so that we could properly merge the two tables.  Ted to discuss with INM.                                                                                         
 +
#**'''Motion'''                                       
 +
#*477 Controlled Substance Schedule
 +
#**Footnotes and citations should probably be in the database, but the asterisk should not be included in the table name.
 +
#**Review with INM; Frank to fix database content.
 +
#**Remove asterisk from table name in the database for all versions.                                   
 +
#**FO: fixed in #78 
 +
#**Asterisk still in table name in v79. 
 +
#**FO: fixed by display_name in #81
 +
#**OK, but we need to decide how it should be rendered in 2C for 2.9.  Ted to reach out to INM for this answer.  Should the footnote be in the table description?  Or is the footnote related to field usage?   
 +
#*10 Physician ID
 +
#**not really a domain or really a code, but is an ID. Need to explain why we assigned it as one.
 +
#**InM needs to determine what if any thing needs to be done.
 +
#**Ask PA and INM if this should be mapped to a concept domain or not since it is conceptually not a code system at all.                                                                           
 
#* DAF update
 
#* DAF update
 
# Other business and planning.
 
# Other business and planning.
 
# Adjournment
 
# Adjournment

Revision as of 19:09, 6 July 2016

logistics

  • Conference call Second Monday of each month at 1:00pm U.S. Eastern
  • Phone audio 1 770 657 9270
  • code 984125#
There is NO DAF reconciliation planned for July 11, so no GTM

Agenda

July 11, 2016

  1. Management
    • Roll Call
    • Minute/Agenda approval Minutes
  2. Methodology
    • Discuss the effort to create machine testable conformance statements in Implementation Guides.
    • Revisit tracker number 3071 - Change the binding to example instead of preferred. and create a representative exemplary value set (Ewout/Peter) – 13-0-0. Updated Tracker.
      • The event value set is generated from the individual resources by the resource creators.
    • Table 211 (see Vocab minutes)
    • PT data type
      • Do we note with what an empty component 2 means in Either or both
        • 2.A.58 PT - processing type
        • 2.14.9.11 MSH-11 Processing ID (PT) 00011
    • 191 Type of Referenced Data
      • Values in the standard do not agree with the values in the database. There are two different sets of values originating in version 2.3.1 listed in two places, with only partial overlap. An additional error in the database seems related to the SGML code in version 2.3.1.
      • Review with WG and Frank to fix in database
      • Ideal solution would be to set ‘Application’, ‘Image’, and ‘Audio’ as synonym codes to AP, IM, and AU, and set them to retired as of 2.4
      • FO: for v2.3.1 virtually deleted in #78
      • Motion to approve setting ‘Application’, ‘Image’, and ‘Audio’ as synonym codes to AP, IM, and AU, and set them to retired as of 2.4.
    • 207 Processing mode
      • There is an entry "Not present" in all versions of the table; this needs to be removed and replaced with a field note on what the meaning of an unpopulated code value is.
      • Ted sent email to Tony on this 12/7/15.
      • Verified code is deprecated (status D) in db86. Ted must clarify with INM that it is not to be simply removed with a note on the field.
      • Motion to deprecate "Not present" from the table and add a field note.
    • 254 Kind of Quantity
      • Values from version 2.3 not appearing in the database. Need to determine if the values are the same as v2.3.1; WG advice sought. Note also that many print names include an asterisk for a footnote in the table commentary. This should probably be changed to text in the Comment column of every table. Advice sought from WG.
      • Review with WG and Frank to fix in database
      • As of v77 2.3 values added back into database. For all codes having printnames with an asterisk, remove the asterisk and add a comment “Adopted from the IUPAC Silver Book 1995” to the code
      • Asterisks still in printnames in #78. Ted to followup up with INM on putting the footnotes into the comment fields for the codes.
      • FO: done in #79, do we need a comment instead? Ted will follow up with INM and OO on this. As of db86, asterisks removed from print names but left in definitions. As the footnote that the asterisk refers to is not part of the vocabulary, should something be done about that? Such as putting the footnote text in the usage note column? Or in the table description? Discuss with INM and ask if having the footnote text in usage note is ok.
      • Motion to approve footnote text.
    • 290 MIME base64 encoding characters
      • the entry from the table for null values - (pad) = - was removed from the database. INM must be asked what should the code system actually contain for this entry, and how it should be rendered (since it has been removed from the database, it will no longer show up in the chapter 2C enumeration of the table).
      • INM must weigh in on what to do about this.
      • still waiting on input from INM. Note that this should probably NOT be an HL7 code system, but it is unclear of what kind of vocabulary object this reference table should be. It has been removed from the 2C output for 2.9; is this correct?
    • 291 Subtype of referenced data
      • as of v2.6, code system was deprecated, and a new value set recommended to be built on RFC2046 plus the HL7 CDA codes. Need to make this a user defined table? Need to check the published MIME types to make sure the CDA subtype is represented in RFC 2064. Need to clarify from INM whether the intent is to include all types from RFC 2064 or only the enumerated subset? Note this is an HL7 table. Are there any IP issues in republishing these values?
      • FO: unclear what to do here? Ted will clarify and update the spreadsheet, after which Frank will apply the necessary changes. Create an enumerated value set based on RFC2064 for this for 2.2 through 2.5.1, and just add the single CDA entry as an enumerated entry in the VSD; not clear what code system it should be drawn from, discuss with Tables project.
      • FO: unclear, need values; we currently work on the same stuff in a value set project for Germany (goal is to support XDS) Ted will discuss with INM.
      • Review with WG and Frank to fix in database. In San Antonio meeting Russ assigned to square this away with INM in conjunction with 290 above.
      • This code system went away as of 2.6; HL7 code system prior to that. After 2.5.1, this is a value set built on RFC2064 all codes plus the one x-cda… code from the original old code system. Update spreadsheet as this is a change to the decisions. Excel sheet updated on 2/25 call. All values removed or set to Deprecated in db86; what is the desire of INM for this output to be?
      • Motion
    • 338 Practitioner ID number type
      • This table has nearly 100% overlap with the content of table 203; retire this code system in v2.9 and this table becomes a value set built on table 203 code system, and add the sole missing value (TRL) to 203, and get rid of the old deprecated L&I code completely. The code system for this table goes away as of 2.9
      • Seek confirmation from INM. Seek advice on what, if anything to do about content in older HL7 v2.x; Frank to implement recommendations.
      • INM ok with this, leave the older stuff as is. TRL will be added to 203 in v2.9. This table will be a value set built on 203, with the TRL code added for the older versions. Value set must be enumerated.
      • FO: we have to do the value set stuff later on, so we need to keep this issue for later Note that the last harmonization meeting (March) had table 203 updates, but the code TRL was *NOT* added to table 203 so that we could properly merge the two tables. Ted to discuss with INM.
      • Motion
    • 477 Controlled Substance Schedule
      • Footnotes and citations should probably be in the database, but the asterisk should not be included in the table name.
      • Review with INM; Frank to fix database content.
      • Remove asterisk from table name in the database for all versions.
      • FO: fixed in #78
      • Asterisk still in table name in v79.
      • FO: fixed by display_name in #81
      • OK, but we need to decide how it should be rendered in 2C for 2.9. Ted to reach out to INM for this answer. Should the footnote be in the table description? Or is the footnote related to field usage?
    • 10 Physician ID
      • not really a domain or really a code, but is an ID. Need to explain why we assigned it as one.
      • InM needs to determine what if any thing needs to be done.
      • Ask PA and INM if this should be mapped to a concept domain or not since it is conceptually not a code system at all.
    • DAF update
  3. Other business and planning.
  4. Adjournment