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

20171101 inm agenda

From HL7Wiki
Jump to navigation Jump to search

InM - Meeting (Date in Title)

Agenda

  1. Call to order
  2. Roll Call
  3. Approval of Agenda and October 25, 2017 Minutes
  4. Management
  5. V2.9 Ballot Reconciliation
    • Motion recap:
    • MOTION to find items 32,33,34,150 (InM-NG1) Persuasive
    • MOTION to find items 45,46,47 persuasive with mod
    • MOTION to find item 35 (INM-NG3) NOT persuasive
    • MOTION to find items 3,42,109,121 (INM-AT) persuasive with mod: Editor will correct.
    • MOTION to find item 36 (INM-AQ1) Persuasive with MODwith the following text added:HL7 provides an OID registry as a convenience to implementers, but there is no requirement to use any specific OID registry.
    • MOTION to find Items 2, 106,108,111(INM-AS1) Persuasive
    • MOTION to find item 151(INM-AS1) Persuasive with mod: Editor will fix consistent with other ack choreographies
    • MOTION to find item 110(INM-AS2) considered for future use, unless 2.9 will be reballoted.
    • Negatives
      • Item 32:Section 2.A.13.14 The changes in 2.A.13.14 and 2.A.13.15 look fine, but it seems like the same changes should be applied to 2.A.13.17, 2.A.13.18, 2.A.13.20 and 2.A.13.21. I suggest you make the same changes in those sections as well.
      • Item 33:Section 2.A.50 The OG (observation grouper) data type was part of 2.8.2 but seems to be missing from 2.9. I'm assuming that is an oversight and that it should be included.
      • Item 34:Section should remain, even with a note about backwards compatibility. Very few implementations use enhanced mode, and retaining original mode would be descriptive for implementers not familiar with enhanced.
      • Item 150:
        • Existing:"Note:The V2.1 original acknowledgment protocol is equivalent to the enhanced acknowledgment protocol with MSH-15-accept acknowledgment type = NE and MSH-16-application acknowledgment type = AL, and with the application acknowledgment message defined so that it never requires an accept acknowledgment (MSH-15-accept acknowledgment type = NE)."
        • Suggested:"Note:There is no equivalent to the V2.1 original acknowledgment protocol, where the acknowledgement is always sent as a response on the same communications channel. The enhanced acknowledgment protocol with MSH-15 (accept acknowledgment type) = NE and MSH-16 (application acknowledgment type) = AL still requires that the application acknowledgement is sent on a separate communications channel."
        • The committee originally voted to deprecate these sections, but in a later action chosed to reverse the decision. The Editor reversed the editing, but did not remove from the change list.
      • Item 45: The ballot notes indicate that 2.9.2 and 2.9.2.1 are deprecated, yet there is no indication of that in the actual sections.
      • Item 46: The ballot notes indicate that the title of 2.9.3 was changed, but it was not.
      • Item 47:The ballot notes indicate that the section was withdrawn, but it was not.
        • While not best practice, historicaly senders have used empty NTE-3 to indicate a blank line when sending print-oriented reports.
      • Item 35:Section 2.14.10.03
        • Existing:When NTE-9 is no populated then NTE-3 MAY be populated.
        • Comment:Senders SHOULD NOT send empty NTEs. Hard to think of an NTE without either NTE-3 or NTE-9. Suggest removing existing wording.
    • A-T - Typos (InM-AT1)
      • Item 3:Section 02 - TOC Right below 2.9.2 - error in generating the TOC.
      • Item 42:Section 2.5.3.5 Correct error message page 14
      • Item 109:Section 02.09.03.0 This section appears to be blank. Remove
      • Item 121:Section 02.17.05
        • Existing:
          • Initiating Message: MSH|^~\&|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03^MFN_M03|MSGID002|P|2.9 MFI|...
          • Response Message: Original mode acknowledgment of the HL7 message according to MFI Response Level Code of AL. MSH|^~\&|ICU||LABxxx|ClinLAB|19910918060545||MFK^M03^MFK_M01|MSGID99002|P|2.8 MSA|AA|MSGID002 MFI|...
        • Suggested:
          • Initiating Message: MSH|^~\&|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03^MFN_M03|MSGID002|P|2.9 MFI|...
          • Response Message: Original mode acknowledgment of the HL7 message according to MFI Response Level Code of AL. MSH|^~\&|ICU||LABxxx|ClinLAB|19910918060545||MFK^M03^MFK_M01|MSGID99002|P|2.9 MSA|AA|MSGID002 MFI|...
    • A-S - Suggestions
      • Item 2: Section02.05.05.02 "Chapter 2.5.5.2 In the example message fragment should be: |1234\P\|
      • Item 106:Section2.04
        • Existing:IBM's SNA LU6.2 and SUN Microsystems's NFS are examples of complete proprietary networks.
        • Suggested:IBM's SNA LU6.2 is an example of a complete proprietary network. IETF NFS is an example of a complete open network.
        • Comment:This statement is outdated since Sun transferred control of NFS to IETF (which has an open standards development process), and Sun no longer even Comment:Senders
      • Item 107: Defered
      • Item 108:Section2.06.01
        • Existing:
          • "/* escape the field separator */
          • substitute( field_separator, \F\ );
          • /* escape the encoding characters */
          • substitute( component_separator, \S\ );
          • substitute( repetition_separator, \R\ );
          • substitute( escape_character, \E\ );
        • Suggested:
          • substitute( escape_character, \E\ );
          • /* escape the field separator */
          • substitute( field_separator, \F\ );
          • /* escape the encoding characters */
          • substitute( component_separator, \S\ );
          • substitute( repetition_separator, \R\ );
        • Comment:When constructing a component you need to substitute the escape character first. If you do it after substituting other delimiters then the escape character may already be present intentionally as part of those sequences, so if you then substitute the escape character you will double escape it and corrupt the data.
      • Item 111:Section2.8.3
        • Existing:A field MAY be deprecated by HL7.
        • Proposed:A field MAY be deprecated by HL7. Before deprecating a field, HL7 SHALL ensure that all message structures which use that field have an appropriate non-deprecated location to move the data.
        • Comment:We broke previous versions of the standard because we deprecated fields with instructions to move the data to other fields, but those replacement fields were in segments not allowed in some message structures. This made it impossible to follow the standard in some cases. For example, PV1-9 and PV1-52 fields were deprecated with a recommendation to use ROL. And AL1-6 was withdrawn with a recommendation to use IAM-11 or IAM-13. However most ADT message structures didn't include ROL or IAM. These inconsistencies have been fixed in the latest V2.9 ballot, however should add an explicit statement not to do that again.
      • Item 151: Section2.13.1.0
        • "Chapter 2.13.1.0 In the table the third column's label could be ""Field value: Enchanced mode Immediate ACK"". There could also be a fourth column labeled ""Field value: enchanced mode application ACK"""
    • A-Q Question
      • Item 36: Does fully qualified OID have to be in the HL7 registry, or is organizational branch sufficient.
        • There is no requirement that any OID be in the HL7 Registry - you may use the registrar of your choice.
  6. Other business and planning
  7. Adjournment

Meeting Information

HL7 ARB Work Group Meeting Minutes

Location: Telcon

Date: 20171101
Time: NOON U.S. Eastern
Facilitator Julian, Tony//Sandy Stuart//Dave Shaver Note taker(s) Julian, Tony//Sandy Stuart//Dave Shaver
Attendee Name Affiliation
X Julian, Tony(Co-Chair) Mayo Clinic
X Stuart, Sandy (Co-Chair) Kaiser Permanente
R Shaver, Dave(Co-Chair) Corepoint Health
X Radov, Nick Optum
Guests
.
.
Legend
X Present
. Absent
R Regrets
Quorum Requirements (Co-chair + 2) Met: Yes

Minutes

Retrieved from "https://wiki.hl7.org/w/index.php?title=20171101_inm_agenda&oldid=148502"