Difference between revisions of "Meeting-20090114"
Jump to navigation
Jump to search
m (→Q3) |
|||
(5 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
'''Wednesday January 14, 2009 Q3 and Q4''' | '''Wednesday January 14, 2009 Q3 and Q4''' | ||
'''Architecture Rollout – SAEAF''' | '''Architecture Rollout – SAEAF''' | ||
− | *Q3 | + | ==Attendance== |
− | + | *Joseph Baptist,baptist@nictiz.nl | |
− | + | *Woody Beeler,woody@beelers.com | |
− | + | *Bernd Blobel,bernd.blobel@klinik.uni-regensberg.de | |
− | + | *Bill Branch,bill.branch@foxsys.com | |
− | + | *Carol Brandon,carolb@ctmresources.com | |
− | + | *Louise Brown,louise.brown@gp.informatics.com | |
− | + | *Hans Buitendijk,hans.buitendijk@siemens.com | |
− | + | *Dave Carlson,david.carlson@va.gov | |
− | + | *Jim Case,jtcase@ucdavis.edu | |
− | + | *Jane Curry,janecurry@healthinfostrategies.com | |
− | + | *Julia Davis,julia.d@argusconnect.com.au | |
− | + | *Mike Davis,mike.davis@va.gov | |
− | + | *Alex de Jong,alex.dejong@siemens.com | |
− | + | *Coletta Dorado,colettad@ctmresources.com | |
− | + | *Krisn Eckerson,keckers@emory.edu | |
− | + | *Rick Geimer,rick@alschulerassociates.com | |
− | + | *Pete Gilbert,peter.gilbert@altarum.org | |
− | + | *Grahame Grieve,grahame@kestral.com.au | |
− | * | + | *Russ Hamm,rhamm@apelon.com |
− | + | *Rob Hausam,robert.hausam@theradoc.com | |
− | + | *Alan Honey,aphoneysys@gmail.com | |
− | + | *Stan Huff,stan.huff@imail.org | |
− | + | *Gaby Jewell,gjewell@cerner.com | |
− | + | *Ted Klein,ted@tklein.com | |
− | + | *Paul Knapp,pknapp@continovation.com | |
− | *****Phase 2, | + | *Sara Knoop,seknoop@us.ibm.com |
+ | *Marc Koehn,mkoehn@infoway.ca | ||
+ | *John Koisch,koisch_john@bah.com | ||
+ | *Austin Kreisler,duz1@cdc.gov | ||
+ | *Lynn Laakso,lynn@hl7.org | ||
+ | *Jobst Landgrebe,jobst.landgrebe@booz.com | ||
+ | *Joann Larson,joann.larson@kp.org | ||
+ | *Jingdong Li,jingdong.li@gmail.com | ||
+ | *Patrick Lody,ployd@infoway-inforoute.ca | ||
+ | *Glen Marshall,glen@grok-a-lot.com | ||
+ | *Mike Martin,mmarti5@clemson.edu | ||
+ | *Ken McCaslin,kenneth.a.mccaslin@questdiagnostics.com | ||
+ | *Vincent Mccauley,vincent@mccauleysoftware.com | ||
+ | *Charlie McCay,charlie@ramseysystems.co.uk | ||
+ | *John Moehrke,john.moehrke@ge.com | ||
+ | *Sean Muir,sean.muir@va.gov | ||
+ | *Suzanne Nagami,suzanne.e.nagami@kp.org | ||
+ | *Ravi Natarajan,ravi.natarajan@nhs.net | ||
+ | *Dale Nelson,dale@zed-logic.com | ||
+ | *Frank Oemig,hl7@oemig.de | ||
+ | *Craig Parker,craigparkermd@gmail.com | ||
+ | *Ron Parker,rparker@infoway.ca | ||
+ | *Amit Popat,apopat@epicsystems.com | ||
+ | *Jari Porrasmaa,jari.porrasmaa@uku.fi | ||
+ | *John Quinn,jquinn@hl7.org | ||
+ | *Rich Rogers,rrogers@us.ibm.com | ||
+ | *Tod Ryal,tryal@cerner.com | ||
+ | *Rik Smithies,rik@nprogram.co.uk | ||
+ | *Tim Snyder,tim.snyder@114sm.com | ||
+ | *Craig Stancl,stancl.craig@mayo.edu | ||
+ | *Greg Thomas,greg.j.thomas@kp.org | ||
+ | *Richard Thoreson,richard.thoreson@samhsa.hhs.gov | ||
+ | *Mark Tucker,mtucker@regenstreif.org | ||
+ | ==Q3== | ||
+ | *John Koisch (JK) presentation: | ||
+ | **Messages (v2, v3), Documents (CDA), now Services (unified field theory) | ||
+ | **Implementable Working Interoperability: | ||
+ | **#Computable Semantic Interoperability | ||
+ | **#Implementable Specifications | ||
+ | **#Conformance model | ||
+ | **Next steps: | ||
+ | ***Capturing semantics: | ||
+ | ***#Behavioral Framework | ||
+ | ***#Binding instance of a dynamic Model to Static models | ||
+ | ***#Other artifacts | ||
+ | **Governance model | ||
+ | ***improves in the current working draft of the SAEAF | ||
+ | **Conformance model | ||
+ | ***adding details and patterns | ||
+ | *Questions: | ||
+ | **Bernd Blobel question: performing this activity needs an orientation; define roadmap direction of next step. Urgent needs of current implementations should not preclude forming small group to define next steps. Way to improve system for ontology driven architecture. He notes the Scientific domain is missing relationship to academic domain represented in this. What are you going to do for us? | ||
+ | **Request for agenda by quarter: Marc Koehn 5-7 mins on rollout project; capture suggestions and inputs. What should be done for momentum maintenance? | ||
+ | *MK [http://newgforge.hl7.nscee.edu/docman/view.php/52/821/HL7-EA-IP-Phase%201%20-%20Wed%20Q3%20Overview.ppt presentation]: | ||
+ | **HL7 enterprise architecture implementation project (HL7 EA IP) | ||
+ | ***Ph 1 EA IP planning/ initiation | ||
+ | ***Overall goal: establish business architecture (BA) to enable HL7 to effectively develop and promulgate spec products consistent with emerging Hl7 Enterprise Architecture Spec (EAS) | ||
+ | ***Conceptual project phases: | ||
+ | ****Phase 0 project planning | ||
+ | ****Phase 1 formal plan, initiate project | ||
+ | ****Phase 2, implementation. | ||
+ | **TSC is responsible for development of Business Architecture (BA) to drive EAS implementation. | ||
+ | ***EAS development responsibility of ArB | ||
+ | ***EA IP primary coordination point to address issue management between alpha projects and HL7 | ||
+ | ***Need to identify impact of EAS IP on day to day work process. | ||
+ | ***Identify momentum maintenance tasks prior to Kyoto. | ||
+ | **Next 3 weeks – phase 1 | ||
+ | ***All work needed to successfully launch implementation phase | ||
+ | ***Maintaining momentum plan communication and coordination activities | ||
+ | **Deliverables: baseline project management materials among others | ||
+ | **TSC working to elaborate a project plan for Phase 1. Further dialog required on phase 1 – planning considerations and worry points, engagement approach, participants. | ||
+ | *Floor Comments | ||
+ | **Jim McCain: project team – how will it be formed? | ||
+ | ***Notion of team versus advisors, is it achievable using normal processes. Make that an objective for today; find interest in engaging in project. (sidebar – government projects/ US FHA would like to participate Jim will be point of contact [POC]) | ||
+ | **Mark Tucker- Before I can get excited about the process, I want to know what “it” is. Don’t see anything new. Unification of messages, documents, and services… | ||
+ | **Woody: As an independent observer’s opinion. Looking for dynamic model that is actually dynamic and is actually a model. Been looking at building new dynamic model to include services concepts since Cologne. There is a Behavioral Model, that has been reviewed. An enhancement of how we’re doing things. It’s not new, but completes a lot of stuff that isn’t/hasn’t been right. | ||
+ | **Glen Marshall, as 42-year developer, sees boundaries between what is health care and what is ‘not health care related’ are very porous. Treating health care as an island when it is not, in the real world… Looking for things that can be implemented at a consumer’s desktop. | ||
+ | **JK clarifies Mark’s statement: | ||
+ | **# they do have something to say about each other, using RM-ODP framework, aspects to w3c security standards that are agnostic but informed by policy of privacy and the semantic models we cope with. | ||
+ | **# each specification row is a layer. HL7 has historically done things in each of those boxes, need to accommodate each of the viewpoints. Building constraints down each column gives you a specification stack. | ||
+ | **Paul Knapp: have we decided to do this, or is there still a decision to be made? Are we merely doing this? What are the decision making practices. | ||
+ | ***CM: we have decided to implement an architecture. That is part of rationale and process for separating ARB activity from rollout. Alpha projects will illustrate value activity of examples whether it will work, when it needs to change. | ||
+ | ***Org is committed to implementing an architecture as defined by ArB, whether it is SAEAF or something else. Formal review process is incomplete. Radical surgery is not in process. What further approval granting process will be part of the project planning. Ultimately it is The TSC responsibility to decide the architecture. | ||
+ | ***Cm - there will be a number of decisions made/ project planning will allow for some appropriate decision points. Need to draw up a list of decision points. This corresponding meeting in Kyoto will not be asked to come to a vote. | ||
+ | ***MK: by or about the time of Kyoto the TSC will have this broken apart to know what decisions need to be made and what the milestones are. | ||
+ | **Mark Tucker - Is this phase 2 of the dynamic model? When we tried to model on interaction diagrams before, the standard collapsed. | ||
+ | **Ken Rubin - Document the process by which the decisions will be made within SD and TSC. What is the process by how decisions will be reached before you know the milestones. Want to know when decision going to be made; want to have notification in advance. Even before the whole plan is put together; if this is how we’re going to go about approving the plan. | ||
+ | ***CM says during 2 to 3 week phase, while defining planning phase, announce how to get process rolling. | ||
+ | ***JK says TSC should also form specific communications plan. | ||
+ | **Grahame - Have we clearly defined success criteria and published the criteria? Long term impacts could have just as significant an effect. Comment on Glen’s on creating an island to of health care. Rollout should reduce creating an island. | ||
+ | **Norman Doust - To alleviate questions and concerns. Need neutral example of all of these artifacts to illustrate from detail of specification constraint pattern. | ||
+ | ***JK responds: reference implementations exist for these; arb is working on identifying these. Reference implementations from Infoway and RUP | ||
+ | |||
+ | ==Q4== | ||
+ | *Discussion continued: | ||
+ | **Hans Bujitenijk, as cochair O&O, We have documentation with HDF, harmonizing the architecture with HDF? There are Terminology variations. | ||
+ | ***CM says yes. Need to timetable that process, changes to handbook, editors’ guide, core principles, etc. | ||
+ | ***Hans further indicated the Dynamic model challenges noted; on the one hand good work being done, actual benefit how much longer to do; we look to when we’ll get answers to help us through challenges? What can we expect by Kyoto if you’re still planning the plan. What can we expect? | ||
+ | ***Grahame responds: status of “behavioral model” (not “dynamic”). Hope to make solid progress tomorrow. | ||
+ | ***CM says Patrick Loyd joining the ArB shortly to help. | ||
+ | ***Patrick has concerns about usability of the specs. Teaching publishing facilitators what to teach, had poor consistency in methodology, etc. Terminology to describe Behavioral Models changed. We had to teach messaging side people the new terminology to understand services. As this becomes clearer and succinct, but modeling “area” becomes more complex. | ||
+ | ***CM worries about new set of vocabulary to teach and learn; need to establish this as a success criterion. | ||
+ | **JK recounted a conversation with Abdul-Malik Shakir (AMS) who had been on ArB and SAEAF group, indicated that it helps provide curricula for those coming into HL7. | ||
+ | **Nancy Orvis - Concern that we will losing majority of current constituency on HL7 by going to services. Need service-aware facilitators for every group? Identify the services aware artifacts that need to be part of each group’s effort. Need to get an idea of change management, what has to change in each product, and how to manage working of that change in that product. | ||
+ | **Jobst Landgrebe - Re-displayed the List of three main artifacts: service role specifications; collaboration specifications, and contracts. Contracts is ok. Need to know what CBDI would do with service role specification? | ||
+ | ***JK: Capabilities in your organization. Tie to application role and receiver responsibility. Service Role Specifications are Expression of a capability. Behavior patterns are collaboration specifications. | ||
+ | **Russ Hamm - How will this affect services currently under development, how to contain, how are things valid at what level. | ||
+ | ***JK migration path is narrow. Proposed that you can ballot an analysis specification and exit at that level. Not decided yet. Need to get to conceptual design to get an implementable specification. | ||
+ | ***CM discussion on whether DAM can be balloted as normative or informative. Discussion ongoing, will have to be determined what balloting is done against different artifacts in the new architecture. | ||
+ | **Grahame asks about Rumors. Please make statement of what we’re not planning - to kill any processes or committees. | ||
+ | ***CM: TSC’s responsibility to worry about what committees exist, what their charters and missions are, what projects are run. ARB determines what the architecture should look like. Those decisions will be made in the SD and TSC. There have been no decisions made around reorganizations or dissolving committees or shifting committees. | ||
+ | **Galen Mulrooney: Tangent – how do big decisions like this get vetted through the larger membership? How does an individual regain their voice through delegated delegated 3rd time removed decision maker. | ||
+ | ***CM: TSC provide transparency to decision making. Smaller decisions coming up to the tsc need to be more visible. Agendas are on the wiki; update from the TSC goes out weekly but only to cochairs. Do people want to see such an email every week to the members list? | ||
+ | ***Ron Parker urges that we let the process work, still in process. He cites the responsibility of the cochairs to disseminate information. | ||
+ | ***Galen wants to know when this is coming up to a vote and who’s voting on it, something this large. | ||
+ | **Jane Curry states that this is too big to plan on the back of a napkin, that’s why we have to plan the plan. Process is open, see the wiki, minutes are detailed, opportunity to weigh in. Not a single decision but a set of decisions and an ongoing process. | ||
+ | **JK: recommendation for success criteria: dedicated sessions to show lessons learned. Though a session may look something like this, but that’s not enough – HL7 needs to provide dedicated rooms for those alpha projects to meet during the week as opposed to committee rooms. | ||
+ | **CM suggests success criteria including a clear mechanism for commenting and including responses to comments. Need to demonstrate commitment to response. | ||
+ | **Rich Rogers: Roles and responsibilities: RASCI mechanism to define set of activities and roles/individuals/groups that have those responsibilities. We found this to be a good mechanism in SOA wg. May have broader use. | ||
+ | **MK: themes he’s hearing - | ||
+ | **#Timing of decisions, | ||
+ | **#Clarity of what the decisions are, | ||
+ | **#RACI mechanism, | ||
+ | **#What makes an alpha project? | ||
+ | ***Would like to hear more comments on achievability of the end game – | ||
+ | ***Impacts of change | ||
+ | **JK states it’s hard to define success criteria when you don’t have a conformance model. ARB wants layered but verifiable conformance model. ARB took as success criteria for SAEAF was that it was verifiable. You could measure whether a standard was HL7 compliant. | ||
+ | **CM asking again - | ||
+ | ***Issues of deliverability | ||
+ | ***Risk it will make life more difficult and create distraction and disruption. Would like to hear expression of the challenges, now is your opportunity. | ||
+ | **Ken Rubin - Issue log, need tool for issue log. | ||
+ | ***CM reminds the group that there is a TSC issue log. We’ll have to have one for this rollout project. | ||
+ | ****ACTION ITEM Lynn get with Wilfred or Dave on using PI versus GForge for project tracking. Issue tracking separate from project management documents? | ||
+ | ****Jane says the project registration in gforge gives it its own issues log. | ||
+ | **Paul Knapp - People don’t have a clue whether this will impact their committees. | ||
+ | ***Doesn’t see that this has been evolved into something that will provide a satisfactory response. | ||
+ | ***Patrick Loyd says this absolutely must impact his committee and needs something to help. | ||
+ | **CM asks: in Kyoto do we want to do another full session like this, 2 quarters to discuss. | ||
+ | ***Woody: If EAF is fairly well evolved by Kyoto you need a quarter just for the tutorial. The ArB finalization of behavioral framework, JK said his quarter tutorial on Monday was not enough. Need a Quarter for tutorial, tutorial for geeks, tutorial for project managers. Woody says 12 years ago they did an all day tutorial on v3, and a half day tutorial just for TSC. | ||
+ | ***MK: What level do you present to a mixed audience? Can have a conversation on what we think the level of completeness is. Need to work to plan that session out, tutorials in advance. Session on content, session for dialogue. | ||
+ | ***CM says we’ll need 1Q for joint meeting Weds pm on rollout project, issues, etc. | ||
+ | **Info in update from TSC weekly as we progress, especially over next few weeks as we approach the end of phase 0. | ||
+ | ***JK reminds all of the ArB meetings tomorrow Q3 and Q4. | ||
+ | |||
+ | Adjourned 4:28 pm. |
Latest revision as of 18:55, 20 January 2009
HL7 WGM Joint Session
Wednesday January 14, 2009 Q3 and Q4 Architecture Rollout – SAEAF
Attendance
- Joseph Baptist,baptist@nictiz.nl
- Woody Beeler,woody@beelers.com
- Bernd Blobel,bernd.blobel@klinik.uni-regensberg.de
- Bill Branch,bill.branch@foxsys.com
- Carol Brandon,carolb@ctmresources.com
- Louise Brown,louise.brown@gp.informatics.com
- Hans Buitendijk,hans.buitendijk@siemens.com
- Dave Carlson,david.carlson@va.gov
- Jim Case,jtcase@ucdavis.edu
- Jane Curry,janecurry@healthinfostrategies.com
- Julia Davis,julia.d@argusconnect.com.au
- Mike Davis,mike.davis@va.gov
- Alex de Jong,alex.dejong@siemens.com
- Coletta Dorado,colettad@ctmresources.com
- Krisn Eckerson,keckers@emory.edu
- Rick Geimer,rick@alschulerassociates.com
- Pete Gilbert,peter.gilbert@altarum.org
- Grahame Grieve,grahame@kestral.com.au
- Russ Hamm,rhamm@apelon.com
- Rob Hausam,robert.hausam@theradoc.com
- Alan Honey,aphoneysys@gmail.com
- Stan Huff,stan.huff@imail.org
- Gaby Jewell,gjewell@cerner.com
- Ted Klein,ted@tklein.com
- Paul Knapp,pknapp@continovation.com
- Sara Knoop,seknoop@us.ibm.com
- Marc Koehn,mkoehn@infoway.ca
- John Koisch,koisch_john@bah.com
- Austin Kreisler,duz1@cdc.gov
- Lynn Laakso,lynn@hl7.org
- Jobst Landgrebe,jobst.landgrebe@booz.com
- Joann Larson,joann.larson@kp.org
- Jingdong Li,jingdong.li@gmail.com
- Patrick Lody,ployd@infoway-inforoute.ca
- Glen Marshall,glen@grok-a-lot.com
- Mike Martin,mmarti5@clemson.edu
- Ken McCaslin,kenneth.a.mccaslin@questdiagnostics.com
- Vincent Mccauley,vincent@mccauleysoftware.com
- Charlie McCay,charlie@ramseysystems.co.uk
- John Moehrke,john.moehrke@ge.com
- Sean Muir,sean.muir@va.gov
- Suzanne Nagami,suzanne.e.nagami@kp.org
- Ravi Natarajan,ravi.natarajan@nhs.net
- Dale Nelson,dale@zed-logic.com
- Frank Oemig,hl7@oemig.de
- Craig Parker,craigparkermd@gmail.com
- Ron Parker,rparker@infoway.ca
- Amit Popat,apopat@epicsystems.com
- Jari Porrasmaa,jari.porrasmaa@uku.fi
- John Quinn,jquinn@hl7.org
- Rich Rogers,rrogers@us.ibm.com
- Tod Ryal,tryal@cerner.com
- Rik Smithies,rik@nprogram.co.uk
- Tim Snyder,tim.snyder@114sm.com
- Craig Stancl,stancl.craig@mayo.edu
- Greg Thomas,greg.j.thomas@kp.org
- Richard Thoreson,richard.thoreson@samhsa.hhs.gov
- Mark Tucker,mtucker@regenstreif.org
Q3
- John Koisch (JK) presentation:
- Messages (v2, v3), Documents (CDA), now Services (unified field theory)
- Implementable Working Interoperability:
- Computable Semantic Interoperability
- Implementable Specifications
- Conformance model
- Next steps:
- Capturing semantics:
- Behavioral Framework
- Binding instance of a dynamic Model to Static models
- Other artifacts
- Capturing semantics:
- Governance model
- improves in the current working draft of the SAEAF
- Conformance model
- adding details and patterns
- Questions:
- Bernd Blobel question: performing this activity needs an orientation; define roadmap direction of next step. Urgent needs of current implementations should not preclude forming small group to define next steps. Way to improve system for ontology driven architecture. He notes the Scientific domain is missing relationship to academic domain represented in this. What are you going to do for us?
- Request for agenda by quarter: Marc Koehn 5-7 mins on rollout project; capture suggestions and inputs. What should be done for momentum maintenance?
- MK presentation:
- HL7 enterprise architecture implementation project (HL7 EA IP)
- Ph 1 EA IP planning/ initiation
- Overall goal: establish business architecture (BA) to enable HL7 to effectively develop and promulgate spec products consistent with emerging Hl7 Enterprise Architecture Spec (EAS)
- Conceptual project phases:
- Phase 0 project planning
- Phase 1 formal plan, initiate project
- Phase 2, implementation.
- TSC is responsible for development of Business Architecture (BA) to drive EAS implementation.
- EAS development responsibility of ArB
- EA IP primary coordination point to address issue management between alpha projects and HL7
- Need to identify impact of EAS IP on day to day work process.
- Identify momentum maintenance tasks prior to Kyoto.
- Next 3 weeks – phase 1
- All work needed to successfully launch implementation phase
- Maintaining momentum plan communication and coordination activities
- Deliverables: baseline project management materials among others
- TSC working to elaborate a project plan for Phase 1. Further dialog required on phase 1 – planning considerations and worry points, engagement approach, participants.
- HL7 enterprise architecture implementation project (HL7 EA IP)
- Floor Comments
- Jim McCain: project team – how will it be formed?
- Notion of team versus advisors, is it achievable using normal processes. Make that an objective for today; find interest in engaging in project. (sidebar – government projects/ US FHA would like to participate Jim will be point of contact [POC])
- Mark Tucker- Before I can get excited about the process, I want to know what “it” is. Don’t see anything new. Unification of messages, documents, and services…
- Woody: As an independent observer’s opinion. Looking for dynamic model that is actually dynamic and is actually a model. Been looking at building new dynamic model to include services concepts since Cologne. There is a Behavioral Model, that has been reviewed. An enhancement of how we’re doing things. It’s not new, but completes a lot of stuff that isn’t/hasn’t been right.
- Glen Marshall, as 42-year developer, sees boundaries between what is health care and what is ‘not health care related’ are very porous. Treating health care as an island when it is not, in the real world… Looking for things that can be implemented at a consumer’s desktop.
- JK clarifies Mark’s statement:
- they do have something to say about each other, using RM-ODP framework, aspects to w3c security standards that are agnostic but informed by policy of privacy and the semantic models we cope with.
- each specification row is a layer. HL7 has historically done things in each of those boxes, need to accommodate each of the viewpoints. Building constraints down each column gives you a specification stack.
- Paul Knapp: have we decided to do this, or is there still a decision to be made? Are we merely doing this? What are the decision making practices.
- CM: we have decided to implement an architecture. That is part of rationale and process for separating ARB activity from rollout. Alpha projects will illustrate value activity of examples whether it will work, when it needs to change.
- Org is committed to implementing an architecture as defined by ArB, whether it is SAEAF or something else. Formal review process is incomplete. Radical surgery is not in process. What further approval granting process will be part of the project planning. Ultimately it is The TSC responsibility to decide the architecture.
- Cm - there will be a number of decisions made/ project planning will allow for some appropriate decision points. Need to draw up a list of decision points. This corresponding meeting in Kyoto will not be asked to come to a vote.
- MK: by or about the time of Kyoto the TSC will have this broken apart to know what decisions need to be made and what the milestones are.
- Mark Tucker - Is this phase 2 of the dynamic model? When we tried to model on interaction diagrams before, the standard collapsed.
- Ken Rubin - Document the process by which the decisions will be made within SD and TSC. What is the process by how decisions will be reached before you know the milestones. Want to know when decision going to be made; want to have notification in advance. Even before the whole plan is put together; if this is how we’re going to go about approving the plan.
- CM says during 2 to 3 week phase, while defining planning phase, announce how to get process rolling.
- JK says TSC should also form specific communications plan.
- Grahame - Have we clearly defined success criteria and published the criteria? Long term impacts could have just as significant an effect. Comment on Glen’s on creating an island to of health care. Rollout should reduce creating an island.
- Norman Doust - To alleviate questions and concerns. Need neutral example of all of these artifacts to illustrate from detail of specification constraint pattern.
- JK responds: reference implementations exist for these; arb is working on identifying these. Reference implementations from Infoway and RUP
- Jim McCain: project team – how will it be formed?
Q4
- Discussion continued:
- Hans Bujitenijk, as cochair O&O, We have documentation with HDF, harmonizing the architecture with HDF? There are Terminology variations.
- CM says yes. Need to timetable that process, changes to handbook, editors’ guide, core principles, etc.
- Hans further indicated the Dynamic model challenges noted; on the one hand good work being done, actual benefit how much longer to do; we look to when we’ll get answers to help us through challenges? What can we expect by Kyoto if you’re still planning the plan. What can we expect?
- Grahame responds: status of “behavioral model” (not “dynamic”). Hope to make solid progress tomorrow.
- CM says Patrick Loyd joining the ArB shortly to help.
- Patrick has concerns about usability of the specs. Teaching publishing facilitators what to teach, had poor consistency in methodology, etc. Terminology to describe Behavioral Models changed. We had to teach messaging side people the new terminology to understand services. As this becomes clearer and succinct, but modeling “area” becomes more complex.
- CM worries about new set of vocabulary to teach and learn; need to establish this as a success criterion.
- JK recounted a conversation with Abdul-Malik Shakir (AMS) who had been on ArB and SAEAF group, indicated that it helps provide curricula for those coming into HL7.
- Nancy Orvis - Concern that we will losing majority of current constituency on HL7 by going to services. Need service-aware facilitators for every group? Identify the services aware artifacts that need to be part of each group’s effort. Need to get an idea of change management, what has to change in each product, and how to manage working of that change in that product.
- Jobst Landgrebe - Re-displayed the List of three main artifacts: service role specifications; collaboration specifications, and contracts. Contracts is ok. Need to know what CBDI would do with service role specification?
- JK: Capabilities in your organization. Tie to application role and receiver responsibility. Service Role Specifications are Expression of a capability. Behavior patterns are collaboration specifications.
- Russ Hamm - How will this affect services currently under development, how to contain, how are things valid at what level.
- JK migration path is narrow. Proposed that you can ballot an analysis specification and exit at that level. Not decided yet. Need to get to conceptual design to get an implementable specification.
- CM discussion on whether DAM can be balloted as normative or informative. Discussion ongoing, will have to be determined what balloting is done against different artifacts in the new architecture.
- Grahame asks about Rumors. Please make statement of what we’re not planning - to kill any processes or committees.
- CM: TSC’s responsibility to worry about what committees exist, what their charters and missions are, what projects are run. ARB determines what the architecture should look like. Those decisions will be made in the SD and TSC. There have been no decisions made around reorganizations or dissolving committees or shifting committees.
- Galen Mulrooney: Tangent – how do big decisions like this get vetted through the larger membership? How does an individual regain their voice through delegated delegated 3rd time removed decision maker.
- CM: TSC provide transparency to decision making. Smaller decisions coming up to the tsc need to be more visible. Agendas are on the wiki; update from the TSC goes out weekly but only to cochairs. Do people want to see such an email every week to the members list?
- Ron Parker urges that we let the process work, still in process. He cites the responsibility of the cochairs to disseminate information.
- Galen wants to know when this is coming up to a vote and who’s voting on it, something this large.
- Jane Curry states that this is too big to plan on the back of a napkin, that’s why we have to plan the plan. Process is open, see the wiki, minutes are detailed, opportunity to weigh in. Not a single decision but a set of decisions and an ongoing process.
- JK: recommendation for success criteria: dedicated sessions to show lessons learned. Though a session may look something like this, but that’s not enough – HL7 needs to provide dedicated rooms for those alpha projects to meet during the week as opposed to committee rooms.
- CM suggests success criteria including a clear mechanism for commenting and including responses to comments. Need to demonstrate commitment to response.
- Rich Rogers: Roles and responsibilities: RASCI mechanism to define set of activities and roles/individuals/groups that have those responsibilities. We found this to be a good mechanism in SOA wg. May have broader use.
- MK: themes he’s hearing -
- Timing of decisions,
- Clarity of what the decisions are,
- RACI mechanism,
- What makes an alpha project?
- Would like to hear more comments on achievability of the end game –
- Impacts of change
- JK states it’s hard to define success criteria when you don’t have a conformance model. ARB wants layered but verifiable conformance model. ARB took as success criteria for SAEAF was that it was verifiable. You could measure whether a standard was HL7 compliant.
- CM asking again -
- Issues of deliverability
- Risk it will make life more difficult and create distraction and disruption. Would like to hear expression of the challenges, now is your opportunity.
- Ken Rubin - Issue log, need tool for issue log.
- CM reminds the group that there is a TSC issue log. We’ll have to have one for this rollout project.
- ACTION ITEM Lynn get with Wilfred or Dave on using PI versus GForge for project tracking. Issue tracking separate from project management documents?
- Jane says the project registration in gforge gives it its own issues log.
- CM reminds the group that there is a TSC issue log. We’ll have to have one for this rollout project.
- Paul Knapp - People don’t have a clue whether this will impact their committees.
- Doesn’t see that this has been evolved into something that will provide a satisfactory response.
- Patrick Loyd says this absolutely must impact his committee and needs something to help.
- CM asks: in Kyoto do we want to do another full session like this, 2 quarters to discuss.
- Woody: If EAF is fairly well evolved by Kyoto you need a quarter just for the tutorial. The ArB finalization of behavioral framework, JK said his quarter tutorial on Monday was not enough. Need a Quarter for tutorial, tutorial for geeks, tutorial for project managers. Woody says 12 years ago they did an all day tutorial on v3, and a half day tutorial just for TSC.
- MK: What level do you present to a mixed audience? Can have a conversation on what we think the level of completeness is. Need to work to plan that session out, tutorials in advance. Session on content, session for dialogue.
- CM says we’ll need 1Q for joint meeting Weds pm on rollout project, issues, etc.
- Info in update from TSC weekly as we progress, especially over next few weeks as we approach the end of phase 0.
- JK reminds all of the ArB meetings tomorrow Q3 and Q4.
- Hans Bujitenijk, as cochair O&O, We have documentation with HDF, harmonizing the architecture with HDF? There are Terminology variations.
Adjourned 4:28 pm.