Difference between revisions of "FTSD-ConCall-20110628"
Jump to navigation
Jump to search
(→Agenda) |
(→Agenda) |
||
| Line 22: | Line 22: | ||
##Who should work on this? | ##Who should work on this? | ||
##Is there any traction from anyone? | ##Is there any traction from anyone? | ||
| − | |||
| − | |||
#''(5 min)'' '''Other Business''' | #''(5 min)'' '''Other Business''' | ||
| − | + | #Adjournment | |
| + | ==Minutes== | ||
| + | #Meeting called to order at 12:00 pm U.S. Eastern | ||
| + | #Agenda approved by affirmation | ||
| + | #''MOTION:'' Approve the agenda of the June 14, 2011 call by Sandy/Beverly | ||
| + | #''VOTE:'' (5-0-0) | ||
| + | #Disposition: HL7 Version 3 Standard: Abstract Transport Specification, Release 1 (V3_TRANSPORT_ABSTRACT_R1_C2_2007JAN ) 1.Last balloted 2007JAN Committee 2 | ||
| + | ##Paul: ITS discussed - ITS does implementable, so we dont do abstract. We dont do, but we did the implementation, using the abstract as a guideline. We see value in condsidering the question more deeply. | ||
| + | ##Tony: Paul, do we clearly have a need? | ||
| + | ##Paul: Maybe we need to review the document, and its relevance to current transports. Rather than throwing it away, we need to get people together to discuss it. The problem is where. ITS is not how we handled concrete. This is an instance of an issue - what happens when people go away. This is an architectural problem for HL7. This is the question facing Tony. At a minimum, I would prefer the decision to remove it stayer, and socialize the issue, and allocate time in September. | ||
| + | ##Beverly: What are the consequences of noone working on it? | ||
| + | ##Paul: InM's intention is to delete. The abstract specifications are to provide overarching guidelines for a family of standards. Without it, you run the risk of standards going off in different direction, not staying true to HL7. The abstract lays out the principles, rather than in peoples heads. In Datatypes, we have an abstract that defines datatype from functional perspective, then we have implementations - XML, UML, ISO, vertical bar. It also means that any implementation has a fundamental thing you will not live up to, you can document why you arent doing it, mapped back to the abstract. The RIM is an abstract of all of the other models. We need to pull the people together to make a decison. Maybe the business case has moved- but i doubt it. Everytime people move away from a document, what are we to do? Are the co-chairs responsible? At the same time, the health of that committee is being judged by that reality. | ||
| + | ##KEN: elevate the question to TSC or ARB. | ||
| + | ##Paul: Two issues to TSC - on this document there is noone on this call who is jumping to do it. InM should push the document to TSC, or discuss with FTSD in September specially SOA, INM, ITS. | ||
| + | ## Tony: Send copy of document to SOA, INM, ITS, MnM. Look for resources | ||
| + | ##Ken: As we redefine, isnt MnM owning SAIF artifact definition? In the new world we should work with SAIF artifacts. | ||
| + | ##Paul: Should go to MnM first. | ||
| + | ##Ken: Aspect of SAIF, or push back. I am worried about the abstract, the binding of SOA belongs to SOA. | ||
| + | ##Paul: I dont want to elevate stuff to TSC, they are getting a lot of stuff, and I am not sure that is a good way to solve issues by punting them off. | ||
| + | ##Tony: is there a need? | ||
| + | ##Paul: ITS believes that there is a deeper review, and the specification is necessary. We dont have time for a detailed review. | ||
| + | ##Ken: Recommend that we approach MnM to take on the work, SOA would participate, if MnM agrees that this is across paradigms. | ||
| + | ##Paul: Consider this is an InM space thing - if MnM wants, they can take it on. | ||
| + | ##Tony: I will discuss with MnM | ||
| + | ##Paul: ITS, SOA, and MnM can bring resources - if only to determine if it needs to be. Then we take the next step. | ||
| + | #Other business - None | ||
| + | Adjourned at 12:30pm U.S. Eastern | ||
| + | [[User:A julian|A julian]] 16:35, 28 June 2011 (UTC) | ||
===[[FTSD Agenda item list|Agenda items]]=== | ===[[FTSD Agenda item list|Agenda items]]=== | ||
===[[FTSD Action item list|Action Item List]]=== | ===[[FTSD Action item list|Action Item List]]=== | ||
[[Foundation_%26_Technology_Meeting_Minutes_and_Agendas|Back to Meetings]] | [[Foundation_%26_Technology_Meeting_Minutes_and_Agendas|Back to Meetings]] | ||
Revision as of 16:35, 28 June 2011
Fndn&Tech Steering Divn - Conference Call (date above)
Meeting Information
- Conference Call is scheduled for 0.5 hour,
- Tuesday 12:00 PM to be repeated every other week
- Please consult http://www.timeanddate.com/worldclock for your local times
- HL7 Conference Call Service
- Phone Number: +1 770-657-9270 (Passcode: 943627)
- Online Meeting Service - GoToMeeting
- https://www2.gotomeeting.com/join/385800034 (GoToMeeting ID: 385-800-034)
Steering Division Members:
- Application Integration & Design (AID)
- Implementable Technology Specifications (ITS)
- Conformance & Guidance for Implementation/Testing(CGIT)
- Infrastructure & Messaging (InM)
- Modeling & Methodology (MnM)
- Security
- Service Oriented Architecture (SOA)
- Templates
- Vocabulary
Attendees
| Facilitator | Note taker | Quorum | |||
| Woody or Tony | Woody or Tony | Yes/No | |||
| Implementable Technology Specifications (ITS) | Implementation/Conformance (InC) | Infrastructure and Messaging (InM) | |||
| . | Knapp, Paul | . | Huang, Wendy | . | Julian, Tony |
| . | Nelson, Dale | . | Oemig, Frank | . | Loyd, Patrick |
| . | Stechishin, Andy | . | Peters, Melva | . | Shaver, Dave |
| . | Snelick, Robert | . | Stuart, Sandy | ||
| Modeling & Methodology (MnM) | RIM-Based Application Architecture (RIMBAA) | Security | |||
| . | Beeler, Woody | . | Hendler MD, Peter | . | Blobel PhD, Bernd |
| . | Duteau, Jean | . | Shabo PhD, Amnon | . | Moehrke, John |
| . | Grieve, Grahame | . | Spronk, Rene | ||
| . | McKenzie, Lloyd | ||||
| . | Natarajan , Ravi | ||||
| Service Oriented Architecture (SOA) | Templates | Vocabulary | |||
| . | Jorgenson, Don | . | Baird, Douglas | . | Case, James |
| . | Mulrooney, Galen | . | Roberts , John | . | Grain, Heather |
| . | Rubin, Ken | . | Shafarman, Mark | . | Hamm, Russell |
| . | Wrightson, Ann | . | Hausam, Rob | ||
| . | Klein, William Ted | ||||
| . | Knight, Beverly | ||||
| Guests | |||||
| . | Laakso, Lynn | ||||
| . | .=Absent, X=Present | ||||
Agenda
- (05 min) Roll Call
- (05 min) Approve Previous Minutes & Accept Agenda
- (15 min) Disposition: HL7 Version 3 Standard: Abstract Transport Specification, Release 1 (V3_TRANSPORT_ABSTRACT_R1_C2_2007JAN )
- Last balloted 2007JAN Committee 2
- Who should work on this?
- Is there any traction from anyone?
- (5 min) Other Business
- Adjournment
Minutes
- Meeting called to order at 12:00 pm U.S. Eastern
- Agenda approved by affirmation
- MOTION: Approve the agenda of the June 14, 2011 call by Sandy/Beverly
- VOTE: (5-0-0)
- Disposition: HL7 Version 3 Standard: Abstract Transport Specification, Release 1 (V3_TRANSPORT_ABSTRACT_R1_C2_2007JAN ) 1.Last balloted 2007JAN Committee 2
- Paul: ITS discussed - ITS does implementable, so we dont do abstract. We dont do, but we did the implementation, using the abstract as a guideline. We see value in condsidering the question more deeply.
- Tony: Paul, do we clearly have a need?
- Paul: Maybe we need to review the document, and its relevance to current transports. Rather than throwing it away, we need to get people together to discuss it. The problem is where. ITS is not how we handled concrete. This is an instance of an issue - what happens when people go away. This is an architectural problem for HL7. This is the question facing Tony. At a minimum, I would prefer the decision to remove it stayer, and socialize the issue, and allocate time in September.
- Beverly: What are the consequences of noone working on it?
- Paul: InM's intention is to delete. The abstract specifications are to provide overarching guidelines for a family of standards. Without it, you run the risk of standards going off in different direction, not staying true to HL7. The abstract lays out the principles, rather than in peoples heads. In Datatypes, we have an abstract that defines datatype from functional perspective, then we have implementations - XML, UML, ISO, vertical bar. It also means that any implementation has a fundamental thing you will not live up to, you can document why you arent doing it, mapped back to the abstract. The RIM is an abstract of all of the other models. We need to pull the people together to make a decison. Maybe the business case has moved- but i doubt it. Everytime people move away from a document, what are we to do? Are the co-chairs responsible? At the same time, the health of that committee is being judged by that reality.
- KEN: elevate the question to TSC or ARB.
- Paul: Two issues to TSC - on this document there is noone on this call who is jumping to do it. InM should push the document to TSC, or discuss with FTSD in September specially SOA, INM, ITS.
- Tony: Send copy of document to SOA, INM, ITS, MnM. Look for resources
- Ken: As we redefine, isnt MnM owning SAIF artifact definition? In the new world we should work with SAIF artifacts.
- Paul: Should go to MnM first.
- Ken: Aspect of SAIF, or push back. I am worried about the abstract, the binding of SOA belongs to SOA.
- Paul: I dont want to elevate stuff to TSC, they are getting a lot of stuff, and I am not sure that is a good way to solve issues by punting them off.
- Tony: is there a need?
- Paul: ITS believes that there is a deeper review, and the specification is necessary. We dont have time for a detailed review.
- Ken: Recommend that we approach MnM to take on the work, SOA would participate, if MnM agrees that this is across paradigms.
- Paul: Consider this is an InM space thing - if MnM wants, they can take it on.
- Tony: I will discuss with MnM
- Paul: ITS, SOA, and MnM can bring resources - if only to determine if it needs to be. Then we take the next step.
- Other business - None
Adjourned at 12:30pm U.S. Eastern A julian 16:35, 28 June 2011 (UTC)
