This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Inm 29 r1 recon"
Jump to navigation
Jump to search
m |
|||
| (11 intermediate revisions by the same user not shown) | |||
| Line 12: | Line 12: | ||
==='''Motion to find Persuasive''' === | ==='''Motion to find Persuasive''' === | ||
====Group InM-2 Items 1,62,65,85,86,87,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147 ==== | ====Group InM-2 Items 1,62,65,85,86,87,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147 ==== | ||
| + | * Approved 20170209 Julian/Stechishin 4-0-1 | ||
<table border="1"><tr><th>"Comment Number"</th><th>Ballot</th><th>Chapter</th><th>Section</th><th>Page #</th><th>Line #</th><th>Vote and Type</th><th>Existing Wording</th><th>Proposed Wording</th><th>Ballot Comment</th><th>Comment grouping</th><th>Disposition</th><th>"Disposition Comment or Retract/Withdraw details"</th></tr> | <table border="1"><tr><th>"Comment Number"</th><th>Ballot</th><th>Chapter</th><th>Section</th><th>Page #</th><th>Line #</th><th>Vote and Type</th><th>Existing Wording</th><th>Proposed Wording</th><th>Ballot Comment</th><th>Comment grouping</th><th>Disposition</th><th>"Disposition Comment or Retract/Withdraw details"</th></tr> | ||
<tr><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>InM-2</td><td></td><td></td></tr> | <tr><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>InM-2</td><td></td><td></td></tr> | ||
| Line 17: | Line 18: | ||
<tr><td>62</td><td>Pub</td><td>2</td><td>2.5.1</td><td>10</td><td></td><td>A-T</td><td>Delete Indicatior</td><td>Delete Indicator</td><td></td><td>InM-2</td><td>Persuasive</td><td></td></tr> | <tr><td>62</td><td>Pub</td><td>2</td><td>2.5.1</td><td>10</td><td></td><td>A-T</td><td>Delete Indicatior</td><td>Delete Indicator</td><td></td><td>InM-2</td><td>Persuasive</td><td></td></tr> | ||
<tr><td>65</td><td></td><td>2</td><td>2.14.13</td><td>78</td><td></td><td>A-T</td><td></td><td></td><td>Remove green highlights of SGH and SGT.</td><td>InM-2</td><td>Persuasive</td><td>Editor will remove highlights</td></tr> | <tr><td>65</td><td></td><td>2</td><td>2.14.13</td><td>78</td><td></td><td>A-T</td><td></td><td></td><td>Remove green highlights of SGH and SGT.</td><td>InM-2</td><td>Persuasive</td><td>Editor will remove highlights</td></tr> | ||
| − | <tr><td>85</td><td></td><td>2</td><td>2.3.2</td><td>6</td><td></td><td>A-C</td><td>(the 3rd paragraph, beginning with:) The HL7 Standard makes no assumptions about the ownership of data.</td><td>(see ballot comment)</td><td>This paragraph is not related to the "Acknowledgements: original mode" title of section 2.3.2. One solution would be to alter the title of 2.3.2. Another would be to move the content to a "box" note, such as the one in sectioin 2.3.1.</td><td>InM-2</td><td>Persuasive</td><td></td></tr> | + | <tr><td>85</td><td></td><td>2</td><td>2.3.2</td><td>6</td><td></td><td>A-C</td><td>(the 3rd paragraph, beginning with:) The HL7 Standard makes no assumptions about the ownership of data.</td><td>(see ballot comment)</td><td>This paragraph is not related to the "Acknowledgements: original mode" title of section 2.3.2. One solution would be to alter the title of 2.3.2. Another would be to move the content to a "box" note, such as the one in sectioin 2.3.1.</td><td>InM-2</td><td>Persuasive</td><td>Editor will use BOX solution</td></tr> |
<tr><td>86</td><td></td><td>2</td><td>2.5.5.0</td><td>13</td><td></td><td>A-T</td><td>The minimum and the maximum length separated by two dots, e.g. m.n</td><td>The minimum and the maximum length separated by two dots, e.g. m..n</td><td>Typo.</td><td>InM-2</td><td>Persuasive</td><td>Editor will fix</td></tr> | <tr><td>86</td><td></td><td>2</td><td>2.5.5.0</td><td>13</td><td></td><td>A-T</td><td>The minimum and the maximum length separated by two dots, e.g. m.n</td><td>The minimum and the maximum length separated by two dots, e.g. m..n</td><td>Typo.</td><td>InM-2</td><td>Persuasive</td><td>Editor will fix</td></tr> | ||
<tr><td>87</td><td></td><td>2</td><td>2.5.6</td><td>15</td><td></td><td>A-S</td><td>The values rows MSH-15 and MSH.16 are extracted from the valid values for the field.</td><td>The values rows MSH-15 and MSH.16 are extracted from the valid values for the field. All possible pairs of values are listed in the following table. Reduce this list to the ones that apply to the use cse at hand, as shown in the example at 2.12.3. </td><td>It will be easier to understand the table if the values used to construct it are available when needed.</td><td>InM-2</td><td>Persuasive</td><td>See comment number 7</td></tr> | <tr><td>87</td><td></td><td>2</td><td>2.5.6</td><td>15</td><td></td><td>A-S</td><td>The values rows MSH-15 and MSH.16 are extracted from the valid values for the field.</td><td>The values rows MSH-15 and MSH.16 are extracted from the valid values for the field. All possible pairs of values are listed in the following table. Reduce this list to the ones that apply to the use cse at hand, as shown in the example at 2.12.3. </td><td>It will be easier to understand the table if the values used to construct it are available when needed.</td><td>InM-2</td><td>Persuasive</td><td>See comment number 7</td></tr> | ||
| Line 36: | Line 37: | ||
<tr><td>147</td><td>pub</td><td>2</td><td>2.14.9.20</td><td>67</td><td></td><td>A-T</td><td></td><td></td><td>Hyperlink still points to Eigene datie v2.8.1 - and is not opening</td><td>InM-2</td><td>Persuasive</td><td>Editor will Fix</td></tr> | <tr><td>147</td><td>pub</td><td>2</td><td>2.14.9.20</td><td>67</td><td></td><td>A-T</td><td></td><td></td><td>Hyperlink still points to Eigene datie v2.8.1 - and is not opening</td><td>InM-2</td><td>Persuasive</td><td>Editor will Fix</td></tr> | ||
</table> | </table> | ||
| − | ==='''Motion to find | + | |
| + | ==='''Motion to find as listed'''=== | ||
====Grouping InM-3 Items 7,8,9,10,23,24,32,63,88,89,90,112,131,132 ==== | ====Grouping InM-3 Items 7,8,9,10,23,24,32,63,88,89,90,112,131,132 ==== | ||
| + | * Approved 20170209 Julian/Stechishin 4-0-1 | ||
| + | *7,23,24,32,88,89 removed from block for further refinement/discussion | ||
| + | *9, 10 persuasive - editor will use provided text | ||
| + | *8,32,63,112,131,132 - persuasuve with mod - Editor will fix as indicated | ||
<table border="1"><tr><th>"Comment Number"</th><th>Ballot</th><th>Chapter</th><th>Section</th><th>Page #</th><th>Line #</th><th>Vote and Type</th><th>Existing Wording</th><th>Proposed Wording</th><th>Ballot Comment</th><th>Comment grouping</th><th>Disposition</th><th>"Disposition Comment or Retract/Withdraw details"</th></tr> | <table border="1"><tr><th>"Comment Number"</th><th>Ballot</th><th>Chapter</th><th>Section</th><th>Page #</th><th>Line #</th><th>Vote and Type</th><th>Existing Wording</th><th>Proposed Wording</th><th>Ballot Comment</th><th>Comment grouping</th><th>Disposition</th><th>"Disposition Comment or Retract/Withdraw details"</th></tr> | ||
| − | <tr><td>7</td><td></td><td>2</td><td>2.5.6</td><td>16-17</td><td></td><td>NEG</td><td>"The values rows MSH-15 and MSH.16 are extracted from the valid values for the field. The rows Immediate ACK and Application ACK are valued with the expected response message based on the definitions in the chapter."</td><td></td><td>Overall, this section is not clear. | + | <tr><td>7</td><td></td><td>2</td><td>2.5.6</td><td>16-17</td><td></td><td>NEG</td><td>"The values rows MSH-15 and MSH.16 are extracted from the valid values for the field. The rows Immediate ACK and Application ACK are valued with the expected response message based on the definitions in the chapter."</td><td></td><td>Overall, this section is not clear. If the first row is the column name, the how are "Immediate Ack" and Application Ack" field names? Why are there sub-columns of the right-most column? Need more explanation of the content in this table.</td><td>InM-3</td><td>Removed from block</td><td>now that I re-read it, you are right.** will remove from block pending editor figuring out a fix </td></tr> |
| − | <tr><td>8</td><td></td><td>2</td><td>2.12.3</td><td>49</td><td></td><td>A-C</td><td>Using the example messages in Error! Unknown switch argument. for the WRQ/WRP message pair:</td><td></td><td>Need to fix error with unknown switch argument.</td><td>InM-3</td><td>Persuasive with Mod</td><td>Editor will fix</td></tr> | + | <tr><td>8</td><td></td><td>2</td><td>2.12.3</td><td>49</td><td></td><td>A-C</td><td>Using the example messages in Error! Unknown switch argument. for the WRQ/WRP message pair:</td><td></td><td>Need to fix error with unknown switch argument.</td><td>InM-3</td><td>Persuasive with Mod</td><td>Editor will fix the broken link</td></tr> |
| − | <tr><td>9</td><td></td><td>2</td><td>2.9.2.1</td><td>31</td><td></td><td>A-S</td><td>Note: Any Acknowledgement Code other than AA SHOULD send the reason(s) for the rejection in ERR segment(s).</td><td>Note: If the Acknowledgement Code is other than AA, the reason(s) for the rejection SHOULD be sent in the ERR segment(s).</td><td>Need to clarify the intention of this statement.</td><td>InM-3</td><td>Persuasive | + | <tr><td>9</td><td></td><td>2</td><td>2.9.2.1</td><td>31</td><td></td><td>A-S</td><td>Note: Any Acknowledgement Code other than AA SHOULD send the reason(s) for the rejection in ERR segment(s).</td><td>Note: If the Acknowledgement Code is other than AA, the reason(s) for the rejection SHOULD be sent in the ERR segment(s).</td><td>Need to clarify the intention of this statement.</td><td>InM-3</td><td>Persuasive</td><td>Editor will fix</td></tr> |
| − | <tr><td>10</td><td></td><td>2</td><td>2.9.2.2</td><td>32</td><td></td><td>A-S</td><td>Note: Any Acknowledgement Code other than AA SHOULD send the reason(s) for the rejection in ERR segment(s).</td><td>Note: If the Acknowledgement Code is other than AA, the reason(s) for the rejection SHOULD be sent in the ERR segment(s).</td><td>Need to clarify the intention of this statement.</td><td>InM-3</td><td>Persuasive | + | <tr><td>10</td><td></td><td>2</td><td>2.9.2.2</td><td>32</td><td></td><td>A-S</td><td>Note: Any Acknowledgement Code other than AA SHOULD send the reason(s) for the rejection in ERR segment(s).</td><td>Note: If the Acknowledgement Code is other than AA, the reason(s) for the rejection SHOULD be sent in the ERR segment(s).</td><td>Need to clarify the intention of this statement.</td><td>InM-3</td><td>Persuasive</td><td>Editor accept text provided.</td></tr> |
| − | <tr><td>23</td><td>Pub</td><td>2</td><td>2.14.10</td><td>70</td><td>n/a</td><td>NEG</td><td>This field contains the comment contained in the segment. In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. When NTE-9 is not populated then NTE-3 MAY be populated.</td><td></td><td>The Usage of NTE-3 is being changed from O to C. Under what conditions would an NTE segment be sent if neither NTE-9 nor NTE-3 are populated? What is the point of such an NTE? If there is a use case for this, please include an explanation in the documentation for the NTE segment. If there is no valid use case, the usage of NTE-3 should be required rather than conditional.</td><td>InM-3</td><td> | + | <tr><td>23</td><td>Pub</td><td>2</td><td>2.14.10</td><td>70</td><td>n/a</td><td>NEG</td><td>This field contains the comment contained in the segment. In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. When NTE-9 is not populated then NTE-3 MAY be populated.</td><td></td><td>The Usage of NTE-3 is being changed from O to C. Under what conditions would an NTE segment be sent if neither NTE-9 nor NTE-3 are populated? What is the point of such an NTE? If there is a use case for this, please include an explanation in the documentation for the NTE segment. If there is no valid use case, the usage of NTE-3 should be required rather than conditional.</td><td>InM-3</td><td>removed from block</td><td>Conditionality predicate needs to be further indicated:In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. When NTE-9 is not populated then NTE-3 MAY be populated.</td></tr> |
| − | <tr><td>24</td><td>Pub</td><td>2</td><td>2.14.10</td><td>70</td><td>n/a</td><td>NEG</td><td>This field contains the comment contained in the segment. In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. When NTE-9 is not populated then NTE-3 MAY be populated.</td><td></td><td>The requirement for NTE-3 to be populated when NTE-9 is populated seems redundant at best given that CWE contains ample numbers of components for text equivalents (CWE.2, CWE.5, CWE.9). At best all of these element are equivalent. At worst, they will have varying meanings and the receiving system will be forced to either store and/or display them all or select one to store/display. In conjunction with my other comment on this field, I would make both NTE-3 and NTE-9 conditional such that one or the other must be populated. If an implemenation guide wants to further constrain and require both, they are free to do so.</td><td>InM-3</td><td> | + | <tr><td>24</td><td>Pub</td><td>2</td><td>2.14.10</td><td>70</td><td>n/a</td><td>NEG</td><td>This field contains the comment contained in the segment. In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. When NTE-9 is not populated then NTE-3 MAY be populated.</td><td></td><td>The requirement for NTE-3 to be populated when NTE-9 is populated seems redundant at best given that CWE contains ample numbers of components for text equivalents (CWE.2, CWE.5, CWE.9). At best all of these element are equivalent. At worst, they will have varying meanings and the receiving system will be forced to either store and/or display them all or select one to store/display. In conjunction with my other comment on this field, I would make both NTE-3 and NTE-9 conditional such that one or the other must be populated. If an implemenation guide wants to further constrain and require both, they are free to do so.</td><td>InM-3</td><td>removed from Block</td><td>See comment number 23</td></tr> |
| − | <tr><td>32</td><td>Pub</td><td>2</td><td>14</td><td>72</td><td></td><td>NEG</td><td>If this field is is valued, NTE-3 will be populated with text from this field.</td><td>If this field is valued, NTE-3 shall be populated with a non-null value from either NTE-9.2, NTE-9.5, or NTE-9.9.</td><td>Typo "is is". | + | <tr><td>32</td><td>Pub</td><td>2</td><td>14</td><td>72</td><td></td><td>NEG</td><td>If this field is is valued, NTE-3 will be populated with text from this field.</td><td>If this field is valued, NTE-3 shall be populated with a non-null value from either NTE-9.2, NTE-9.5, or NTE-9.9.</td><td>Typo "is is". And need to clarify "with text from this field".</td><td>InM-3</td><td>Remove from block</td><td>for further refinement/discussion</td></tr> |
| − | <tr><td>63</td><td></td><td>2</td><td>2.5.6</td><td></td><td></td><td>NEG</td><td></td><td></td><td>Propose to adjust the diagram so the first row becomes a table name title as done for other tables. | + | <tr><td>63</td><td></td><td>2</td><td>2.5.6</td><td></td><td></td><td>NEG</td><td></td><td></td><td>Propose to adjust the diagram so the first row becomes a table name title as done for other tables. (see Chapter 4 Acknowledgement Choreography table layout).</td><td>InM-3</td><td>Persuasive with Mod</td><td>Will modifyd diagram to align with Chapter 4.</td></tr> |
| − | <tr><td>88</td><td></td><td>2</td><td>2.5.6</td><td>16</td><td></td><td>A-S</td><td>(no text to replace)</td><td>The Field Values for MSH-15 and MSH-16 are normative in Table 0155 and are: AL = Always send acknoeledgement; ER = Send acknowledgement on error conditions; NE = Never send acknowledgements; SU = on successful message processing.</td><td></td><td>InM-3</td><td> | + | <tr><td>88</td><td></td><td>2</td><td>2.5.6</td><td>16</td><td></td><td>A-S</td><td>(no text to replace)</td><td>The Field Values for MSH-15 and MSH-16 are normative in Table 0155 and are: AL = Always send acknoeledgement; ER = Send acknowledgement on error conditions; NE = Never send acknowledgements; SU = on successful message processing.</td><td></td><td>InM-3</td><td>Removed from block</td><td>See comment number 7 ** will remove from block pending editor figuring out a fix </td></tr> |
| − | <tr><td>89</td><td></td><td>2</td><td>2.5.6</td><td>16</td><td></td><td>A-S</td><td>The rows Immediate ACK and Application ACK are valued with the expected response message based on the definitions in the chapter.</td><td>The Immediate ACK row should contain the message expected in reponse to the processing of the message named in second row containing the value(s) for MSH-15 in that column.</td><td>A definition for Immediate ACK should be | + | <tr><td>89</td><td></td><td>2</td><td>2.5.6</td><td>16</td><td></td><td>A-S</td><td>The rows Immediate ACK and Application ACK are valued with the expected response message based on the definitions in the chapter.</td><td>The Immediate ACK row should contain the message expected in reponse to the processing of the message named in second row containing the value(s) for MSH-15 in that column.</td><td>A definition for Immediate ACK should be provided.</td><td>InM-3</td><td>Removed from block</td><td>See comment number 7 ** will remove from block pending editor figuring out a fix </td></tr> |
| − | <tr><td>90</td><td></td><td>2</td><td>2.5.6</td><td>16</td><td></td><td>A-S</td><td>(same existing wording as the previous comment; proposed wording is an addition..)</td><td>The Applicatioin ACK row should contain the message expected in reponse to the processing of the message named in third row containing the value(s) for MSH-16 in that column.</td><td></td><td>InM-3</td><td> | + | <tr><td>90</td><td></td><td>2</td><td>2.5.6</td><td>16</td><td></td><td>A-S</td><td>(same existing wording as the previous comment; proposed wording is an addition..)</td><td>The Applicatioin ACK row should contain the message expected in reponse to the processing of the message named in third row containing the value(s) for MSH-16 in that column.</td><td></td><td>InM-3</td><td>Removed from block</td><td>See comment number 7 ** will remove from block pending editor figuring out a fix </td></tr> |
| − | <tr><td>112</td><td></td><td>2</td><td>2.6.1</td><td>17</td><td></td><td>A-T</td><td></td><td>Message Construction</td><td>This section is missing a heading and in the ToC it just shows up as "17".</td><td>InM-3</td><td>Persuasive with mod</td><td>Editor will fix</td></tr> | + | <tr><td>112</td><td></td><td>2</td><td>2.6.1</td><td>17</td><td></td><td>A-T</td><td></td><td>Message Construction</td><td>This section is missing a heading and in the ToC it just shows up as "17".</td><td>InM-3</td><td>Persuasive with mod</td><td>Editor will fix **The modification is that the suggestion does not contain exact fix. The editor will have to do whatever is necessary to fix the heading and TOC.</td></tr> |
| − | <tr><td>131</td><td>InM</td><td>2</td><td>Notes to Balloters </td><td>1</td><td></td><td>A-S</td><td> and to build the HL7 v2.4 Database</td><td> and to build the HL7 v2.9 Database</td><td></td><td>InM-3</td><td>Persuasive with mod</td><td>Editor will fix if re-balloted</td></tr> | + | <tr><td>131</td><td>InM</td><td>2</td><td>Notes to Balloters</td><td>1</td><td></td><td>A-S</td><td>and to build the HL7 v2.4 Database</td><td>and to build the HL7 v2.9 Database</td><td></td><td>InM-3</td><td>Persuasive with mod</td><td>Editor will fix if re-balloted</td></tr> |
| − | <tr><td>132</td><td>InM</td><td>2</td><td>Notes to Balloters </td><td>2</td><td></td><td>A-Q</td><td>TXA - Transcription Document Header Segmen</td><td></td><td>unsure what this change refers to - the section name does not exisit - I assumed it referes to adding the NOTE box in sections 2.9.2.1 and 2.9.2.2 - which is fine as is.</td><td>InM-3</td><td>Persuasive with mod</td><td>Editor will fix | + | <tr><td>132</td><td>InM</td><td>2</td><td>Notes to Balloters</td><td>2</td><td></td><td>A-Q</td><td>TXA - Transcription Document Header Segmen</td><td></td><td>unsure what this change refers to - the section name does not exisit - I assumed it referes to adding the NOTE box in sections 2.9.2.1 and 2.9.2.2 - which is fine as is.</td><td>InM-3</td><td>Persuasive with mod</td><td>Editor will fix</td></tr> |
</table> | </table> | ||
| − | ==='''Motion to find | + | |
| + | ==='''Motion to find Not Related '''=== | ||
==== Group InM-4 Items 59,61,102,103,104 ==== | ==== Group InM-4 Items 59,61,102,103,104 ==== | ||
| + | * Approved 20170209 Julian/Stechishin 4-0-1 | ||
<table border="1"><tr><th>"Comment Number"</th><th>Ballot</th><th>Chapter</th><th>Section</th><th>Page #</th><th>Line #</th><th>Vote and Type</th><th>Existing Wording</th><th>Proposed Wording</th><th>Ballot Comment</th><th>Comment grouping</th><th>Disposition</th><th>"Disposition Comment or Retract/Withdraw details"</th></tr> | <table border="1"><tr><th>"Comment Number"</th><th>Ballot</th><th>Chapter</th><th>Section</th><th>Page #</th><th>Line #</th><th>Vote and Type</th><th>Existing Wording</th><th>Proposed Wording</th><th>Ballot Comment</th><th>Comment grouping</th><th>Disposition</th><th>"Disposition Comment or Retract/Withdraw details"</th></tr> | ||
| − | <tr><td>59</td><td></td><td>2</td><td>2.14.28</td><td></td><td></td><td>NEG</td><td>"BHS-8 Batch Security (ST) 00088 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified."</td><td></td><td>Batch Header BHS_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. See Comment about MSH-8.</td><td>InM-4</td><td> | + | <tr><td>59</td><td></td><td>2</td><td>2.14.28</td><td></td><td></td><td>NEG</td><td>"BHS-8 Batch Security (ST) 00088 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified."</td><td></td><td>Batch Header BHS_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. See Comment about MSH-8.</td><td>InM-4</td><td>Not Related</td><td>IMHO: Not Related for this ballot. This should be submitted as a change proposal.</td></tr> |
| − | <tr><td>61</td><td></td><td>2</td><td></td><td></td><td></td><td>NEG</td><td>"MSH-8 Security (ST) 00008 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified."</td><td></td><td>"MSH_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. Examples of how this might be implemented are summarized from a draft state HIE ADT IG: Although the MSH-8 Security element is singular with a string datatype, it is possible for a local specification, which would be non-compliant in a manner that is widely practiced in the industry, for example in Centers for Disease Control HL7 v2 message specification to implement a quasi-coded work-around. Such an approach would support the adjudication of the MSH-8 Security coded values by an access control system used by an intermediary or end point. This work-around would require senders to add a default set of Security Label Privacy Tags required by their policy domain. There could be 1..* such default sets, but there are likely a fairly limited number of defaults, which senders would select based on the sensitivity of the content being sent and the authorization of their intended recipients. This work-around adds Header Level Security Label Privacy Tags as multiple values in this element delimited by commas. Note that the default Header Level Security Label Privacy Tags for the MSH-8 will likely be a subset of the full set of Security Label Privacy Tags conveying the governing Privacy policy or Patient Consent Directive for this message content. An example of this approach being considered for adoption for HIE exchange of 42 CFR Part 2 substance use disorder V2 Message, Batch, and File headers for ADT and other V2 Messages, and aligned with metadata used in other HL7 product lines are: • Confidentiality = R (restricted) • Purpose of Use = TREAT (treatment), HPAYMT (healthcare payment), HOPERAT (healthcare operations)• Obligation = PERSISTLABEL (persist security label), PRIVMARK (privacy mark)• Refrain = NORDSCLCD (no redisclosure without consent directive)"</td><td>InM-4</td><td> | + | <tr><td>61</td><td></td><td>2</td><td></td><td></td><td></td><td>NEG</td><td>"MSH-8 Security (ST) 00008 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified."</td><td></td><td>"MSH_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. Examples of how this might be implemented are summarized from a draft state HIE ADT IG: Although the MSH-8 Security element is singular with a string datatype, it is possible for a local specification, which would be non-compliant in a manner that is widely practiced in the industry, for example in Centers for Disease Control HL7 v2 message specification to implement a quasi-coded work-around. Such an approach would support the adjudication of the MSH-8 Security coded values by an access control system used by an intermediary or end point. This work-around would require senders to add a default set of Security Label Privacy Tags required by their policy domain. There could be 1..* such default sets, but there are likely a fairly limited number of defaults, which senders would select based on the sensitivity of the content being sent and the authorization of their intended recipients. This work-around adds Header Level Security Label Privacy Tags as multiple values in this element delimited by commas. Note that the default Header Level Security Label Privacy Tags for the MSH-8 will likely be a subset of the full set of Security Label Privacy Tags conveying the governing Privacy policy or Patient Consent Directive for this message content. An example of this approach being considered for adoption for HIE exchange of 42 CFR Part 2 substance use disorder V2 Message, Batch, and File headers for ADT and other V2 Messages, and aligned with metadata used in other HL7 product lines are: • Confidentiality = R (restricted) • Purpose of Use = TREAT (treatment), HPAYMT (healthcare payment), HOPERAT (healthcare operations)• Obligation = PERSISTLABEL (persist security label), PRIVMARK (privacy mark)• Refrain = NORDSCLCD (no redisclosure without consent directive)"</td><td>InM-4</td><td>Not Related</td><td>IMHO: Not Related for this ballot. This should be submitted as a change proposal.</td></tr> |
| − | <tr><td>102</td><td></td><td>2</td><td>2.14.28</td><td></td><td></td><td>NEG</td><td>"BHS-8 Batch Security (ST) 00088 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified."</td><td></td><td>Batch Header BHS_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. See Comment about MSH-8.</td><td>InM-4</td><td> | + | <tr><td>102</td><td></td><td>2</td><td>2.14.28</td><td></td><td></td><td>NEG</td><td>"BHS-8 Batch Security (ST) 00088 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified."</td><td></td><td>Batch Header BHS_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. See Comment about MSH-8.</td><td>InM-4</td><td>Not Related</td><td>IMHO: Not Related for this ballot. This should be submitted as a change proposal.</td></tr> |
| − | <tr><td>103</td><td></td><td>2</td><td>2.14.6.8</td><td></td><td></td><td>NEG</td><td>"FHS-8 File Security (ST) 00074 Definition: This field has the same definition as the corresponding field in the MSH segment."</td><td></td><td>FSH_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. See comment about MSH-8.</td><td>InM-4</td><td> | + | <tr><td>103</td><td></td><td>2</td><td>2.14.6.8</td><td></td><td></td><td>NEG</td><td>"FHS-8 File Security (ST) 00074 Definition: This field has the same definition as the corresponding field in the MSH segment."</td><td></td><td>FSH_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. See comment about MSH-8.</td><td>InM-4</td><td>Not Related</td><td>IMHO: Not Related for this ballot. This should be submitted as a change proposal.</td></tr> |
| − | <tr><td>104</td><td></td><td>2</td><td></td><td></td><td></td><td>NEG</td><td>"MSH-8 Security (ST) 00008 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified."</td><td></td><td>"MSH_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. Examples of how this might be implemented are summarized from a draft state HIE ADT IG: Although the MSH-8 Security element is singular with a string datatype, it is possible for a local specification, which would be non-compliant in a manner that is widely practiced in the industry, for example in Centers for Disease Control HL7 v2 message specification to implement a quasi-coded work-around. Such an approach would support the adjudication of the MSH-8 Security coded values by an access control system used by an intermediary or end point. This work-around would require senders to add a default set of Security Label Privacy Tags required by their policy domain. There could be 1..* such default sets, but there are likely a fairly limited number of defaults, which senders would select based on the sensitivity of the content being sent and the authorization of their intended recipients. This work-around adds Header Level Security Label Privacy Tags as multiple values in this element delimited by commas. Note that the default Header Level Security Label Privacy Tags for the MSH-8 will likely be a subset of the full set of Security Label Privacy Tags conveying the governing Privacy policy or Patient Consent Directive for this message content. An example of this approach being considered for adoption for HIE exchange of 42 CFR Part 2 substance use disorder V2 Message, Batch, and File headers for ADT and other V2 Messages, and aligned with metadata used in other HL7 product lines are: • Confidentiality = R (restricted) • Purpose of Use = TREAT (treatment), HPAYMT (healthcare payment), HOPERAT (healthcare operations)• Obligation = PERSISTLABEL (persist security label), PRIVMARK (privacy mark)• Refrain = NORDSCLCD (no redisclosure without consent directive)"</td><td>InM-4</td><td> | + | <tr><td>104</td><td></td><td>2</td><td></td><td></td><td></td><td>NEG</td><td>"MSH-8 Security (ST) 00008 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified."</td><td></td><td>"MSH_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. Examples of how this might be implemented are summarized from a draft state HIE ADT IG: Although the MSH-8 Security element is singular with a string datatype, it is possible for a local specification, which would be non-compliant in a manner that is widely practiced in the industry, for example in Centers for Disease Control HL7 v2 message specification to implement a quasi-coded work-around. Such an approach would support the adjudication of the MSH-8 Security coded values by an access control system used by an intermediary or end point. This work-around would require senders to add a default set of Security Label Privacy Tags required by their policy domain. There could be 1..* such default sets, but there are likely a fairly limited number of defaults, which senders would select based on the sensitivity of the content being sent and the authorization of their intended recipients. This work-around adds Header Level Security Label Privacy Tags as multiple values in this element delimited by commas. Note that the default Header Level Security Label Privacy Tags for the MSH-8 will likely be a subset of the full set of Security Label Privacy Tags conveying the governing Privacy policy or Patient Consent Directive for this message content. An example of this approach being considered for adoption for HIE exchange of 42 CFR Part 2 substance use disorder V2 Message, Batch, and File headers for ADT and other V2 Messages, and aligned with metadata used in other HL7 product lines are: • Confidentiality = R (restricted) • Purpose of Use = TREAT (treatment), HPAYMT (healthcare payment), HOPERAT (healthcare operations)• Obligation = PERSISTLABEL (persist security label), PRIVMARK (privacy mark)• Refrain = NORDSCLCD (no redisclosure without consent directive)"</td><td>InM-4</td><td>Not Related</td><td>IMHO: Not Related for this ballot. This should be submitted as a change proposal.</td></tr> |
</table> | </table> | ||
| − | ==='''Motion to find | + | |
| + | ==='''Motion to find Not Related '''=== | ||
====Group InM-5 Item 98==== | ====Group InM-5 Item 98==== | ||
| + | * Approved 20170209 Julian/Stechishin 4-0-1 | ||
<table border="1"><tr><th>"Comment Number"</th><th>Ballot</th><th>Chapter</th><th>Section</th><th>Page #</th><th>Line #</th><th>Vote and Type</th><th>Existing Wording</th><th>Proposed Wording</th><th>Ballot Comment</th><th>Comment grouping</th><th>Disposition</th><th>"Disposition Comment or Retract/Withdraw details"</th></tr> | <table border="1"><tr><th>"Comment Number"</th><th>Ballot</th><th>Chapter</th><th>Section</th><th>Page #</th><th>Line #</th><th>Vote and Type</th><th>Existing Wording</th><th>Proposed Wording</th><th>Ballot Comment</th><th>Comment grouping</th><th>Disposition</th><th>"Disposition Comment or Retract/Withdraw details"</th></tr> | ||
<tr><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>InM-5</td><td></td><td></td></tr> | <tr><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td>InM-5</td><td></td><td></td></tr> | ||
| − | <tr><td>98</td><td></td><td>2</td><td>2.14.9.6</td><td>63</td><td></td><td>A-A</td><td>Definition: This field identifies the receiving application … Cardinality 1..1</td><td>Definition: This field identifies the receiving applications … Cardinality 1..*</td><td>There is a requirement in Public Health to direct messages to multiple receivers, either receiving applications or receiving facilities. Normally these multiple receivers are known to the sender but it is possiblethat they are not. The proposed wording is probably not the best solution but it represents a starting point for the discussion. </td><td>InM-5</td><td> | + | <tr><td>98</td><td></td><td>2</td><td>2.14.9.6</td><td>63</td><td></td><td>A-A</td><td>Definition: This field identifies the receiving application … Cardinality 1..1</td><td>Definition: This field identifies the receiving applications … Cardinality 1..*</td><td>There is a requirement in Public Health to direct messages to multiple receivers, either receiving applications or receiving facilities. Normally these multiple receivers are known to the sender but it is possiblethat they are not. The proposed wording is probably not the best solution but it represents a starting point for the discussion. </td><td>InM-5</td><td>Not Related</td><td>This comment suggests a change that needs to be in a change proposal, not as ballot comment.</td></tr> |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
</table> | </table> | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 16:23, 13 February 2017
Contents
InM V2.9 R1 Reconciliation
Evote 2016-02-09 - Chapter 2
- Comment Grouping refers to the grouping used in the Evote.
Motion to find Answered
Group InM-1 Items 6, 91
| "Comment Number" | Ballot | Chapter | Section | Page # | Line # | Vote and Type | Existing Wording | Proposed Wording | Ballot Comment | Comment grouping | Disposition | "Disposition Comment or Retract/Withdraw details" |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 6 | 2 | 2.5.3.0 | 10 | Delete Indicatior: Any | Is this intended to be Indicator or Indication? | InM-1 | Answered | Text is correct: The term delete indicator is used in CP2 to refer to athe double quote characters used to indicate that the field is to be deleted. | ||||
| 91 | 2 | 2.8.3.f) | 28 | A-Q | f) A field MAY be deprecated by HL7. Implementers, by site agreement, MAY agree to not use deprecated fields. | What is the reasoning behind this? | InM-1 | Answered | Fields are deprecated when their use is replaced by other fields . . See ERR.1 for an example. |
Motion to find Persuasive
Group InM-2 Items 1,62,65,85,86,87,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147
- Approved 20170209 Julian/Stechishin 4-0-1
| "Comment Number" | Ballot | Chapter | Section | Page # | Line # | Vote and Type | Existing Wording | Proposed Wording | Ballot Comment | Comment grouping | Disposition | "Disposition Comment or Retract/Withdraw details" |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| InM-2 | ||||||||||||
| 1 | PUB | 2 | 2.9.3.3 | 33 | NEG | Table: ERR-1-Error Code and Location - As described in section 2.14.5.1. Populated if an error condition is found. | ERR segment fields Refer to section 2.15.5. | ERR-1 is withdrawn, so should not be refered to. | InM-2 | Persuasive | Needs to be fixed | |
| 62 | Pub | 2 | 2.5.1 | 10 | A-T | Delete Indicatior | Delete Indicator | InM-2 | Persuasive | |||
| 65 | 2 | 2.14.13 | 78 | A-T | Remove green highlights of SGH and SGT. | InM-2 | Persuasive | Editor will remove highlights | ||||
| 85 | 2 | 2.3.2 | 6 | A-C | (the 3rd paragraph, beginning with:) The HL7 Standard makes no assumptions about the ownership of data. | (see ballot comment) | This paragraph is not related to the "Acknowledgements: original mode" title of section 2.3.2. One solution would be to alter the title of 2.3.2. Another would be to move the content to a "box" note, such as the one in sectioin 2.3.1. | InM-2 | Persuasive | Editor will use BOX solution | ||
| 86 | 2 | 2.5.5.0 | 13 | A-T | The minimum and the maximum length separated by two dots, e.g. m.n | The minimum and the maximum length separated by two dots, e.g. m..n | Typo. | InM-2 | Persuasive | Editor will fix | ||
| 87 | 2 | 2.5.6 | 15 | A-S | The values rows MSH-15 and MSH.16 are extracted from the valid values for the field. | The values rows MSH-15 and MSH.16 are extracted from the valid values for the field. All possible pairs of values are listed in the following table. Reduce this list to the ones that apply to the use cse at hand, as shown in the example at 2.12.3. | It will be easier to understand the table if the values used to construct it are available when needed. | InM-2 | Persuasive | See comment number 7 | ||
| 133 | InM | 2 | 2.5.3.0 | 10 | A-T | Delete Indicatior: | Delete Indicatior: | InM-2 | Persuasive | Editor will fix | ||
| 134 | InM | 2 | 2.5.6 | 16 | A-T | It is required to document the expected acknowledgement based on the values in MSH.15 and MSH.16. | It is required to document the expected acknowledgement based on the values in MSH-15 and MSH-16. | should use the "-" not the "." for field level numbering | InM-2 | Persuasive | Editor will fix | |
| 135 | InM | 2 | 2.5.6 | 16 | A-T | The values rows MSH-15 and MSH.16 | The values rows MSH-15 and MSH-16 | should use the "-" not the "." for field level numbering | InM-2 | Persuasive | Editor will fix | |
| 136 | InM | 2 | 2.5.6 | 17 | A-T | MSH.15 | MSH-15 | should use the "-" not the "." for field level numbering | InM-2 | Persuasive | Editor will fix | |
| 137 | InM | 2 | 2.5.6 | 17 | A-T | MSH.16 | MSH-16 | should use the "-" not the "." for field level numbering | InM-2 | Persuasive | Editor will fix | |
| 138 | InM | 2 | 2.9.3.2 | 32 | A-T | MSH-6 Receiving Facility, andMSH-11 Processing ID | MSH-6 Receiving Facility, and MSH-11 Processing ID | "and" "MSH-11" | InM-2 | Persuasive | Editor will fix | |
| 139 | InM | 2 | 2.12.3 | 49 | A-C | Using the example messages in Error! Unknown switch argument. for the WRQ/WRP message pair: | Fix whatever was here that created this document error | InM-2 | Persuasive | Editor will fix | ||
| 140 | InM | 2 | 2.12.3 | 49 | A-T | MSH:15 is Always, and MSH.16 | MSH-15 is Always, and MSH-16 | "should use the ""-"" not the ""."" for field level numbering : is not correct here" | InM-2 | Persuasive | Editor will fix | |
| 141 | InM | 2 | 2.12.3 | 49 | A-T | When MSH:15 is blank or Never, and MSH.16 | When MSH-15 is blank or Never, and MSH-16 | "should use the ""-"" not the ""."" for field level numbering : is not correct here" | InM-2 | Persuasive | Editor will fix | |
| 142 | InM | 2 | 2.12.3 | 49 | A-T | When MSH:15 is Always, and MSH.15 is Always | When MSH-15 is Always, and MSH-16 is Always | "should use the ""-"" not the ""."" for field level numbering : is not correct here the second MSH should be -16" | InM-2 | Persuasive | Editor will fix | |
| 143 | InM | 2 | 2.12.3 | 50 | A-T | MSH.15 | MSH-15 | should use the "-" not the "." for field level numbering | InM-2 | Persuasive | Editor will fix | |
| 144 | InM | 2 | 2.12.3 | 50 | A-T | MSH.16 | MSH-16 | should use the "-" not the "." for field level numbering | InM-2 | Persuasive | Editor will fix | |
| 145 | InM | 2 | 2.13.10.1.0 | 50 | A-T | MSH.15 | MSH-15 | should use the "-" not the "." for field level numbering | InM-2 | Persuasive | Editor will fix | |
| 146 | InM | 2 | 2.13.10.1.0 | 50 | A-T | MSH.16 | MSH-16 | should use the "-" not the "." for field level numbering | InM-2 | Persuasive | Editor will fix | |
| 147 | pub | 2 | 2.14.9.20 | 67 | A-T | Hyperlink still points to Eigene datie v2.8.1 - and is not opening | InM-2 | Persuasive | Editor will Fix |
Motion to find as listed
Grouping InM-3 Items 7,8,9,10,23,24,32,63,88,89,90,112,131,132
- Approved 20170209 Julian/Stechishin 4-0-1
- 7,23,24,32,88,89 removed from block for further refinement/discussion
- 9, 10 persuasive - editor will use provided text
- 8,32,63,112,131,132 - persuasuve with mod - Editor will fix as indicated
| "Comment Number" | Ballot | Chapter | Section | Page # | Line # | Vote and Type | Existing Wording | Proposed Wording | Ballot Comment | Comment grouping | Disposition | "Disposition Comment or Retract/Withdraw details" |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 7 | 2 | 2.5.6 | 16-17 | NEG | "The values rows MSH-15 and MSH.16 are extracted from the valid values for the field. The rows Immediate ACK and Application ACK are valued with the expected response message based on the definitions in the chapter." | Overall, this section is not clear. If the first row is the column name, the how are "Immediate Ack" and Application Ack" field names? Why are there sub-columns of the right-most column? Need more explanation of the content in this table. | InM-3 | Removed from block | now that I re-read it, you are right.** will remove from block pending editor figuring out a fix | |||
| 8 | 2 | 2.12.3 | 49 | A-C | Using the example messages in Error! Unknown switch argument. for the WRQ/WRP message pair: | Need to fix error with unknown switch argument. | InM-3 | Persuasive with Mod | Editor will fix the broken link | |||
| 9 | 2 | 2.9.2.1 | 31 | A-S | Note: Any Acknowledgement Code other than AA SHOULD send the reason(s) for the rejection in ERR segment(s). | Note: If the Acknowledgement Code is other than AA, the reason(s) for the rejection SHOULD be sent in the ERR segment(s). | Need to clarify the intention of this statement. | InM-3 | Persuasive | Editor will fix | ||
| 10 | 2 | 2.9.2.2 | 32 | A-S | Note: Any Acknowledgement Code other than AA SHOULD send the reason(s) for the rejection in ERR segment(s). | Note: If the Acknowledgement Code is other than AA, the reason(s) for the rejection SHOULD be sent in the ERR segment(s). | Need to clarify the intention of this statement. | InM-3 | Persuasive | Editor accept text provided. | ||
| 23 | Pub | 2 | 2.14.10 | 70 | n/a | NEG | This field contains the comment contained in the segment. In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. When NTE-9 is not populated then NTE-3 MAY be populated. | The Usage of NTE-3 is being changed from O to C. Under what conditions would an NTE segment be sent if neither NTE-9 nor NTE-3 are populated? What is the point of such an NTE? If there is a use case for this, please include an explanation in the documentation for the NTE segment. If there is no valid use case, the usage of NTE-3 should be required rather than conditional. | InM-3 | removed from block | Conditionality predicate needs to be further indicated:In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. When NTE-9 is not populated then NTE-3 MAY be populated. | |
| 24 | Pub | 2 | 2.14.10 | 70 | n/a | NEG | This field contains the comment contained in the segment. In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. When NTE-9 is not populated then NTE-3 MAY be populated. | The requirement for NTE-3 to be populated when NTE-9 is populated seems redundant at best given that CWE contains ample numbers of components for text equivalents (CWE.2, CWE.5, CWE.9). At best all of these element are equivalent. At worst, they will have varying meanings and the receiving system will be forced to either store and/or display them all or select one to store/display. In conjunction with my other comment on this field, I would make both NTE-3 and NTE-9 conditional such that one or the other must be populated. If an implemenation guide wants to further constrain and require both, they are free to do so. | InM-3 | removed from Block | See comment number 23 | |
| 32 | Pub | 2 | 14 | 72 | NEG | If this field is is valued, NTE-3 will be populated with text from this field. | If this field is valued, NTE-3 shall be populated with a non-null value from either NTE-9.2, NTE-9.5, or NTE-9.9. | Typo "is is". And need to clarify "with text from this field". | InM-3 | Remove from block | for further refinement/discussion | |
| 63 | 2 | 2.5.6 | NEG | Propose to adjust the diagram so the first row becomes a table name title as done for other tables. (see Chapter 4 Acknowledgement Choreography table layout). | InM-3 | Persuasive with Mod | Will modifyd diagram to align with Chapter 4. | |||||
| 88 | 2 | 2.5.6 | 16 | A-S | (no text to replace) | The Field Values for MSH-15 and MSH-16 are normative in Table 0155 and are: AL = Always send acknoeledgement; ER = Send acknowledgement on error conditions; NE = Never send acknowledgements; SU = on successful message processing. | InM-3 | Removed from block | See comment number 7 ** will remove from block pending editor figuring out a fix | |||
| 89 | 2 | 2.5.6 | 16 | A-S | The rows Immediate ACK and Application ACK are valued with the expected response message based on the definitions in the chapter. | The Immediate ACK row should contain the message expected in reponse to the processing of the message named in second row containing the value(s) for MSH-15 in that column. | A definition for Immediate ACK should be provided. | InM-3 | Removed from block | See comment number 7 ** will remove from block pending editor figuring out a fix | ||
| 90 | 2 | 2.5.6 | 16 | A-S | (same existing wording as the previous comment; proposed wording is an addition..) | The Applicatioin ACK row should contain the message expected in reponse to the processing of the message named in third row containing the value(s) for MSH-16 in that column. | InM-3 | Removed from block | See comment number 7 ** will remove from block pending editor figuring out a fix | |||
| 112 | 2 | 2.6.1 | 17 | A-T | Message Construction | This section is missing a heading and in the ToC it just shows up as "17". | InM-3 | Persuasive with mod | Editor will fix **The modification is that the suggestion does not contain exact fix. The editor will have to do whatever is necessary to fix the heading and TOC. | |||
| 131 | InM | 2 | Notes to Balloters | 1 | A-S | and to build the HL7 v2.4 Database | and to build the HL7 v2.9 Database | InM-3 | Persuasive with mod | Editor will fix if re-balloted | ||
| 132 | InM | 2 | Notes to Balloters | 2 | A-Q | TXA - Transcription Document Header Segmen | unsure what this change refers to - the section name does not exisit - I assumed it referes to adding the NOTE box in sections 2.9.2.1 and 2.9.2.2 - which is fine as is. | InM-3 | Persuasive with mod | Editor will fix |
Motion to find Not Related
Group InM-4 Items 59,61,102,103,104
- Approved 20170209 Julian/Stechishin 4-0-1
| "Comment Number" | Ballot | Chapter | Section | Page # | Line # | Vote and Type | Existing Wording | Proposed Wording | Ballot Comment | Comment grouping | Disposition | "Disposition Comment or Retract/Withdraw details" |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 59 | 2 | 2.14.28 | NEG | "BHS-8 Batch Security (ST) 00088 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified." | Batch Header BHS_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. See Comment about MSH-8. | InM-4 | Not Related | IMHO: Not Related for this ballot. This should be submitted as a change proposal. | ||||
| 61 | 2 | NEG | "MSH-8 Security (ST) 00008 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified." | "MSH_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. Examples of how this might be implemented are summarized from a draft state HIE ADT IG: Although the MSH-8 Security element is singular with a string datatype, it is possible for a local specification, which would be non-compliant in a manner that is widely practiced in the industry, for example in Centers for Disease Control HL7 v2 message specification to implement a quasi-coded work-around. Such an approach would support the adjudication of the MSH-8 Security coded values by an access control system used by an intermediary or end point. This work-around would require senders to add a default set of Security Label Privacy Tags required by their policy domain. There could be 1..* such default sets, but there are likely a fairly limited number of defaults, which senders would select based on the sensitivity of the content being sent and the authorization of their intended recipients. This work-around adds Header Level Security Label Privacy Tags as multiple values in this element delimited by commas. Note that the default Header Level Security Label Privacy Tags for the MSH-8 will likely be a subset of the full set of Security Label Privacy Tags conveying the governing Privacy policy or Patient Consent Directive for this message content. An example of this approach being considered for adoption for HIE exchange of 42 CFR Part 2 substance use disorder V2 Message, Batch, and File headers for ADT and other V2 Messages, and aligned with metadata used in other HL7 product lines are: • Confidentiality = R (restricted) • Purpose of Use = TREAT (treatment), HPAYMT (healthcare payment), HOPERAT (healthcare operations)• Obligation = PERSISTLABEL (persist security label), PRIVMARK (privacy mark)• Refrain = NORDSCLCD (no redisclosure without consent directive)" | InM-4 | Not Related | IMHO: Not Related for this ballot. This should be submitted as a change proposal. | |||||
| 102 | 2 | 2.14.28 | NEG | "BHS-8 Batch Security (ST) 00088 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified." | Batch Header BHS_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. See Comment about MSH-8. | InM-4 | Not Related | IMHO: Not Related for this ballot. This should be submitted as a change proposal. | ||||
| 103 | 2 | 2.14.6.8 | NEG | "FHS-8 File Security (ST) 00074 Definition: This field has the same definition as the corresponding field in the MSH segment." | FSH_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. See comment about MSH-8. | InM-4 | Not Related | IMHO: Not Related for this ballot. This should be submitted as a change proposal. | ||||
| 104 | 2 | NEG | "MSH-8 Security (ST) 00008 Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified." | "MSH_8 Security is a string with a limit of 40 characters. In order to support jurisdictional privacy and security policies using the HL7 HCS Security and Privacy Tag syntax and vocabulary, which is used in every other HL7 product family, this element must be changed from a string to an appropriate V2 flavor of Coded with Extension in order to support these use cases. The industry has long ago migrated to automated access control systems that are capable of enforcing policies based on standard encoded policy codes. HL7 V2.9 needs to progress to the minimal level of current technology in this area. Examples of how this might be implemented are summarized from a draft state HIE ADT IG: Although the MSH-8 Security element is singular with a string datatype, it is possible for a local specification, which would be non-compliant in a manner that is widely practiced in the industry, for example in Centers for Disease Control HL7 v2 message specification to implement a quasi-coded work-around. Such an approach would support the adjudication of the MSH-8 Security coded values by an access control system used by an intermediary or end point. This work-around would require senders to add a default set of Security Label Privacy Tags required by their policy domain. There could be 1..* such default sets, but there are likely a fairly limited number of defaults, which senders would select based on the sensitivity of the content being sent and the authorization of their intended recipients. This work-around adds Header Level Security Label Privacy Tags as multiple values in this element delimited by commas. Note that the default Header Level Security Label Privacy Tags for the MSH-8 will likely be a subset of the full set of Security Label Privacy Tags conveying the governing Privacy policy or Patient Consent Directive for this message content. An example of this approach being considered for adoption for HIE exchange of 42 CFR Part 2 substance use disorder V2 Message, Batch, and File headers for ADT and other V2 Messages, and aligned with metadata used in other HL7 product lines are: • Confidentiality = R (restricted) • Purpose of Use = TREAT (treatment), HPAYMT (healthcare payment), HOPERAT (healthcare operations)• Obligation = PERSISTLABEL (persist security label), PRIVMARK (privacy mark)• Refrain = NORDSCLCD (no redisclosure without consent directive)" | InM-4 | Not Related | IMHO: Not Related for this ballot. This should be submitted as a change proposal. |
Motion to find Not Related
Group InM-5 Item 98
- Approved 20170209 Julian/Stechishin 4-0-1
| "Comment Number" | Ballot | Chapter | Section | Page # | Line # | Vote and Type | Existing Wording | Proposed Wording | Ballot Comment | Comment grouping | Disposition | "Disposition Comment or Retract/Withdraw details" |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| InM-5 | ||||||||||||
| 98 | 2 | 2.14.9.6 | 63 | A-A | Definition: This field identifies the receiving application … Cardinality 1..1 | Definition: This field identifies the receiving applications … Cardinality 1..* | There is a requirement in Public Health to direct messages to multiple receivers, either receiving applications or receiving facilities. Normally these multiple receivers are known to the sender but it is possiblethat they are not. The proposed wording is probably not the best solution but it represents a starting point for the discussion. | InM-5 | Not Related | This comment suggests a change that needs to be in a change proposal, not as ballot comment. |
