20121210 inm teleconference

1. Call to order (2 min.)
2. Roll Call (1 min.)
3. Approval of November 26, 2012 Minutes /Agenda(2 min.)
4. Status of V2.8
5. Abstract transport discussion
   1. Abstract Transport document
   2. http://gforge.hl7.org/gf/download/docmanfileversion/7086/9895/20121112_V3_TRANSPORT_ABSTRACT_R1_C2_2007JAN_20121025.xls reconciliation package]

1. Item:88
   1. Section:General
   2. Vote:Neg-Mj
   3. Existing: N/A
   4. Proposed:N/A
   5. "This specification takes a broad view of the responsibilities of a messaging endpoint, ie, an HL7 messaging application, and its available networks for message transport. This specification is literally creating requirements to direct or control concepts, networks, messages, and so on that are pretty clearly outside of the HL7 application, and thus outside of the scope of HL7. Why else try to define requirements such as ""at least on delivery."" It's conceivable that HL7 messages will live in environments where this is _not_ a factor, or where it is sublimated into a larger transport or persistence structure. It would be more appropriate to allow this specification to focus solely on Messaging Adapters for different technologies and specifications (say SOAP or JMS) and leave aside any notion that HL7 can positively influence those portions of the industry that are outside its scope of influence. I note that HL7 2 did quite well without making mandates of the TCP/IP or the UDP communicatin protocols, and that the world wide web grew on top of HTTP without making demands."
2. Item:89
   1. Section:General
   2. Vote:Neg-Mj
   3. Existing: N/A
   4. Proposed:N/A
   5. "This specification attempts to make normative an ad-hoc integration architecture. Instead of declaring the adapters, gateways, bridges, etc. this specification could reference them as external design patterns in an informative specification. Selection of relevant patterns is indeed of value to the industry and it ensures the use of common terminology - especially in interaction design patterns. In its current form, the fact that the ATS is normative will be of great concern to HL7 adopters as it imposes a set of very specific components that may or may not apply to an implementation as well as renaming and Existing: patterns. This specification nwould be more useful if it attempted to explain how known artchitectures and solution (EAI, SOA. ,etc.) could take advantage of the message payloads defined by HL7. Attempting to identify a set of adapters,. gateways, routers, etc. does not require a normative specification and it sets artificial limiations for implementers and emerging standard specifications (e.g. HSSP).
3. Item:90
   1. Section:1.2
   2. Vote:A-S
   3. Existing: sends an accept-level acknowledgment
   4. Proposed: N/A
   5. The abstract specification should provide a general-purpose guidance to implementing accept/enhanced ack in certain technology. For example, is a CE a failure mode in WS?
4. Item:91
   1. Section:3.2
   2. Vote:A-S
   3. Existing:Message Adapter Acknowledgment
   4. Proposed N/A
   5. see 1.2
5. Item:92
   1. Section:3.2
   2. Vote:Neg-Mi
   3. Existing:Transmission Wrapper
   4. Proposed N/A
   5. The use of 'wrappers' instead of message envelopes makes it near impossible for implementers to adhere to this specfiication in an abstract way because the HL7 wrappers are not really wrappers but envelopers. The wrappers are not really wrappers in the common "wrapper design pattern" meaning of the term. The use of the term pattern in HL7 is contradictory with the accepted terms and design pattern. The choice is either to define 'HL7 wrappers" as "HL7 envelopes" or reference message envelopes.
6. Other business and planning
   1. Next meeting January 7,2012
7. Adjournment