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 17: Line 17:
 
#* Revisit tracker number [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3071 3071] - Change the binding to example instead of preferred.  and create a representative exemplary value set (Ewout/Peter) – 13-0-0.  Updated Tracker.
 
#* Revisit tracker number [http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=3071 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.
 
#**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
 
#* 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.   
 
#**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.   
Line 32: Line 27:
 
#**Ted sent email to Tony on this 12/7/15.
 
#**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.                 
 
#**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.              
+
#**'''Motion''' to deprecate "Not present" from the table and add a field note.  
 +
#**'''Vote'''             
 
#* 254 Kind of Quantity
 
#* 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.
 
#**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.
Line 39: Line 35:
 
#**Asterisks still in printnames in #78.  Ted to followup up with INM on putting the footnotes into the comment fields for the codes.                                                         
 
#**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.         
 
#**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.                                                       
+
#**'''Motion''' to approve footnote text.
 +
#**'''Vote'''                                                      
 
#* 290 MIME base64 encoding characters
 
#* 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).
 
#**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.
 
#**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?                                                              
+
#**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?  
 +
#**'''Motion''' to remove from 2.c. since not used since 2.4.
 +
#**'''Vote'''
 
#*291 Subtype of referenced data
 
#*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?     
 
#**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?     
Line 50: Line 49:
 
#**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.
 
#**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?     
 
#**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'''                   
+
#** Cdes not in iana are PICT, JOT, x-hl7-cda-level-one
 +
#**'''Motion''' to refer to HTA to add to Iana (Heather Grain and Sandy Stuart)
 +
#**'''Vote'''
 +
#**'''Motion''' to remove, and refer as an external code system https://www.iana.org/assignments/media-types/media-types.xml 
 +
#**'''Vote'''                   
 
#*338 Practitioner ID number type
 
#*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
 
#**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
Line 56: Line 59:
 
#**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.
 
#**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.                                                                                           
 
#**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'''                                         
+
#**'''Motion''' to refer to harmonization. (Tony reach out to Riki)
 +
#**Code is TRL - Training License Number.
 +
#**'''Motion''' to deprecate the code L&I as a duplicate code with LI in table 338.
 +
#**'''Vote'''                                         
 
#*477 Controlled Substance Schedule
 
#*477 Controlled Substance Schedule
 
#**Footnotes and citations should probably be in the database, but the asterisk should not be included in the table name.
 
#**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.
 
#**Review with INM; Frank to fix database content.
−
#**Remove asterisk from table name in the database for all versions.                                    
+
#**Remove asterisk from table name in the database for all versions.
 
#**FO: fixed in #78   
 
#**FO: fixed in #78   
 
#**Asterisk still in table name in v79.   
 
#**Asterisk still in table name in v79.   
 
#**FO: fixed by display_name in #81
 
#**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?     
 
#**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?     
 +
#**'''Motion''' to move the footnote to the table description and remove the asterisk from the table name.
 +
#**'''Vote'''
 
#*10 Physician ID
 
#*10 Physician ID
 
#**not really a domain or really a code, but is an ID. Need to explain why we assigned it as one.
 
#**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.
 
#**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.                                                                          
+
#**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.  
 +
#**'''Motion'''  Refer to PA, and ask them if they want to deal with it in 2.9, or deal with it in ballot reconcillation. 
 +
#**'''Vote'''                                                         
 
#* DAF update
 
#* DAF update
 
# Other business and planning.
 
# Other business and planning.
 
# Adjournment
 
# Adjournment

Revision as of 19:43, 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.
    • 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.
      • Vote
    • 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.
      • Vote
    • 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?
      • Motion to remove from 2.c. since not used since 2.4.
      • Vote
    • 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?
      • Cdes not in iana are PICT, JOT, x-hl7-cda-level-one
      • Motion to refer to HTA to add to Iana (Heather Grain and Sandy Stuart)
      • Vote
      • Motion to remove, and refer as an external code system https://www.iana.org/assignments/media-types/media-types.xml
      • Vote
    • 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 to refer to harmonization. (Tony reach out to Riki)
      • Code is TRL - Training License Number.
      • Motion to deprecate the code L&I as a duplicate code with LI in table 338.
      • Vote
    • 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?
      • Motion to move the footnote to the table description and remove the asterisk from the table name.
      • Vote
    • 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.
      • Motion Refer to PA, and ask them if they want to deal with it in 2.9, or deal with it in ballot reconcillation.
      • Vote
    • DAF update
  3. Other business and planning.
  4. Adjournment
Retrieved from "https://wiki.hl7.org/w/index.php?title=2015-c1-Inm_current-info&oldid=122585"