2009-05-09 TSC WGM Minutes

TSC - Technical Steering Committee

Saturday, May 9, 2009 9:00 AM Kyoto (8:00 PM Friday May 8 - US Eastern Time, GMT -5)

back to TSC Minutes and Agendas

Agenda

Q1

Meeting Admin

• Roll Call - The following individuals joined the call:

Name	Affiliation	Email Address
Calvin Beebe	HL7	cbeebe@mayo.edu
Woody Beeler	HL7	woody@beelers.com
Jim Case	HL7	jtcase@ucdavis.edu
John Koisch	HL7	jkoisch@guidewirearchitecture.com
Lynn Laakso (scribe)	HL7	lynn@hl7.oirg
Ken McCaslin	HL7	Kenneth.H.McCaslin@questdiagnostics.com
Charlie McCay (chair)	HL7	charlie@ramseysystems.co.uk
Charlie Mead	HL7	charlie.mead@booz.com
Ravi Natarajan	HL7	Ravi.Natarajan@nhs.net
John Quinn	HL7	jquinn@hl7.org

• Chair: TSC Meeting chair – John Koisch initially transferred to Charlie McCay 9:15AM

• Accept Agenda – agenda accepted with addition to Q4 to discuss remaining agenda items for WGM
• Approve Minutes from 2009-04-27_TSC_Call_Minutes – postponed
• ArB Report
  • Six areas for SAEAF
    • Section 0 is Elevator Pitch/ Snapshot
    • Section 1 is Intro
    • 2, 3, 4 are ECCF, BF, Gov’nance
    • Implementation Guide
    • Examples/Lessons Learned/Alpha Projects
  • Need more robust way of managing content. Mead suggests like medical textbook. Over 400 pages. In LV talked about setting up technical editing and publishing project. John reports getting proposal from Jay and Sara, and needing approval from finance committee. Mead refers that Woody wants us to go to a publishing process like DITA. Woody suggests that it is missing an artifact repository as they use in tooling. Material needs to tie in to MIF. Discussion ensued on whether the HDF would be balloted, and so would publishing concerns be at the forefront.
  • Koisch added three decisions came to in LV; one that the impacts on MIF or any legacy HL7 structures would not necessarily be solved as part of this project. Two, ArB felt strongly that should look objectively at meta models defining HL7’s larger work. Ultimately publication framework must align with metamodels. Thirdly, notion of the SAEAF as a book. Poor experience with sparc Ca or other forms for publishing. Mead recounts trying to update ECCF and realizing how many other places the same updates needed to be made in the other documents for consistency.
  • Alpha projects need to be able to publish pragmatically. Recommendation by ArB. Need a ballot path to make value for these alpha projects’ artifacts. SAEAF book could be treated as a piloting process. HDF is one format, MIF another.
  • Woody recounts their format was initially copied from W3C. Datatypes, core principles are going to be migrated into MIF format, as storage format; not to say what the book form looks like. Storage structure and visual representation are different. HDF about 2 years ago said they would model on enterprise architect (unsupported by HL7). Would like to see it documented in parallel structure to MIF.
  • Mead: problem with SAEAF book to solve is non trivial content with shifting dependencies. Short term manage six months’ change. Mid range goal is HL7 overall direction for format.
  • McCay says publishing, tooling and maybe MnM responsible for longer term how to maintain content. Not being maintained well in development environment.
  • Koisch suggests it be treated as project, with a couple people focused on solving it rather than at a whole committee level (publishing, tooling).
  • McCaslin says those committees should be asked for direction and support. Ken would welcome them to come to SD. Koisch doesn’t want it to get lost in a committee.
  • Woody said a red flag was to go to Jay and Sara without input from any other groups and some other groups have developed their own publishing format.
  • Marc says we need hard timelines so project is appropriate format. Need a way to ensure initiatives meet requirements, eliminate overlap, align shift and adjust. What is our change management process to make accountability for cross matching requirements.
  • Mead addresses concerns of parochial attitude. Solving SAEAF book problem could be example of how done across organization. Not trying to go around publishing committee. Realized the amount of technical editing, graphics work was more than they could expect from a committee. Then, take it to publishing for input and guidance. NCI barely hanging on with change management process, need to get it under control or it will fail.
  • Quinn wants to know how we can get drafts of a few documents into this committee to review and provide feedback. Not trying to solve world hunger, need to meet immediate need to get drafts for review.
  • McCay says original V3 publishing taskforce had ten people in a room for five days and came out with an approach. Consequences persisted a long time. This committee needs an answer for the ArB by the end of week for produce and maintain documents, to fit in to organization strategy.
  • Koisch agrees that approach is appropriate; the only way this is going to get done. Put the people together (face time or virtual).
  • McCay continues, in asking Woody who should be involved. Woody says he should solicit his group (Matt Brandebur, Referred by Dale Nelson) for involvement. Mead says Matt had hoped to be the Publishing liaison. Koehn says that is step 1 of more. Needs to be understanding that as it is evolved we understand the gap of where publishing was going anyway.
  • McCay: clear project in production of SAEAF book; less clear project in producing HL7 publication environment and underlying technical representations responsible for advice and guidance of development of narrative content (other HL7 books). Whose guidance is needed? Woody says Publishing has developed SVN support structure for source material. If you don’t understand SVN, how do we direct someone – responsibility hasn’t been accepted today. If they ask TSC, how should we be doing this? Woody says those that are off on their own did not receive that direction from Publishing… Need to converse with ArB periodically to ensure that end of process comes out with coherent strategy.
  • Mead says strategy of the four people working on it now, Sara & Jay on technical editing, Chris on graphics, Matt as Publishing Liaison. Charlie is generating content. McCay says we need a document to list what is our publication strategy that says, for example, HDF is being published in Enterprise Architecture and describe whether this is an exception to the Cochairs handbook guidence that will be supported, or will either the document or co-chairs handbook change in future?
  • Mead says EA IP has as execution thread to publish SAEAF book. McCay asks what decision are we looking for? Looking at new publication process potentially, or just use DTD. If we’re going to ask the board for money for a project, TSC should know about it. Koehn says stream of activity should be documented as one of the major streams, as well as major documents, who endorses the steps. Mccay says there are three activities: SAEAF book production, EA IP, and HL7 Publishing strategy. Pub strategy needs one side of A4 (page of paper) that says what we’re doing about compliance to, and development of, the publishing handbook for the organization. This should include a list of all projects know to be publishing an a way that is not covered by the handbook, and what we are doing to manage the exceptions
  • Ravi asks if we foresee problems with going from documents and slide decks for the alpha projects to some new documentation format. Mead says he’s involved with many of the alpha projects that are looking for us to solve the problem with what we’re addressing. Koehn wants to be sure that it addresses the requirements of that documentation. Koisch recounts that HDF and core principles will be rolled into the SAEAF book. Mead says HDF becomes SAEAF implementation guide. Koisch says they talked with Woody and Loyd on core principles rolling into SAEAF book at LV. Ken supports the notions.
  • McCay summarized that publishing has clear responsibility for publishing handbook, including guidance on narrative documents that may be produced in a way that diverges from that guidence. Mead says it will delve into how it needs to become sufficient. Publishing handbook maintenance document will have description as how organization for managing divergence. “Publishing maintains publishing handbook providing guidance to all HL7 project on how to produce documents. When divergence is needed, a description will be maintained by publishing in strategy document to include how re-convergence will be achieved.” As resolved by TSC. Next suggestion by Calvin to committees that already divergent from approach that they have onus to share why they are doing it and what requirements we not being met by publishing strategy to use another format.
  • If people want to publish in nonconformant format to publishing handbook format, rationale must be provided to and agreed by Publishing committee, or appealed to TSC.
  • Technical editing and graphical editing content can begin on SAEAF book, must plan to publish using the publishing handbook guidelines. Escalation of issues is not expected, should be worked out using Matt as liaison.
  • Accountability rests with Publishing for governance – check and balance- on approval of publication content to meet guidelines, and adherence for Publishing strategy. Requirement is that Publishing make visible that strategy document. Publishing is gatekeeper, and decision criteria is transparent.
  • Done with publishing issues, move on to content.
  • Progress or resourcing issues on SAEAF book? Mead says Quinn responsible for getting money to pay for this. It will not happen in our timelines with volunteers, need half a graphics person and Matt, but matt has volunteered time so far. Marc’s time is needed to produce artifacts by September meeting if SAEAF book contents are ready. McCay’s concern with resourcing requirements same as EA IP, what we don’t want is to find out if we don’t have money it will grind to a halt. Quinn is reasonably confident that funding can be obtained. McCay says John needs to be aware if that funding is needed e.g. Marc.
    • Marc needs to know where the dividing lines are for governance, and hopes that a few hours can be spent this week. Publishing has been discussed, but Tooling has not been decided. Alpha project commitments are only the first two but don’t know the others’ level of resource commitment.
    • McCay says he wants to see the balance of resourcing we’re looking to achieve between board funding, committee contributions, alpha project funding or volunteer contribution. Shall we make the requirement that alpha projects must be self-sustaining and what is that definition?
    • Mead asks if that will differ between internal and external projects. Commercial software timelines on external projects are stiff; internal projects are softer on timelines. Discussed in Vegas that could have internal and external but external would probably deliver by September where internal projects may take more unto January. II4sm and NCI are just starting, not asking for support.
    • Koisch asks what oversight this group will have over alpha projects.
    • Woody says NCI advantage is they are resourced, disadvantage to HL7 that it is behind closed doors.
    • Mead says they (NCI) do want their content to be balloted. They are adopting SAEAF, using SAEAF. The more that SAEAF is understood the more that NCI’s work will be open to HL7 to see a clear mapping from what NCI produced to where it fits. Concern is if HL7 moves the goal posts.
    • McCay says we now have a clear process for how to find if you have publishable artifacts.
    • Mead says at Oracle they thought if they did things that were supposedly compliant but were a little ahead of the curve; if they were put back into the mix they might get permuted, and they would make the changes necessary if the permutations make sense. Imagine the alpha projects will be same. HL7 may introduce changes but the organizations commit to be standards-compliant and are committed to making changes if necessary. Suggested Charlie McCay’s earlier approach with NCI architecture may be a good framing document to use. McCay suggests it may be appropriate to add to GOM as status to activity.
  • Break -

Q2 –

• joined by Jim Case.
• Marc’s Presentation – HL7 EA IP Moving Closer! To Phase 2
• Discussion regarding existing artifacts such as DMIMs, RMIMs, CMETs, etc. (“Product”) will likely continue to exist, maybe under a new name, or re-characterized. Koisch reiterated that an authoritative statement from the TSC would be helpful. Alpha projects will surface required changes but we have no V3 messaging alpha project yet to specifically address this. We’ve provided a framework but we still need a message-based product to exercise that. Don’t wish to hatch busywork to provide these answers. We need such a project to surface and relieve this tension. Koisch goes further to suggest that we endorse the ArB’s approach. Serialized information structures of common content should fit into these artifacts whether sent by message or service.
• Existing committees already producing a large percentage of artifacts required, but perhaps not to the degree needed by SAEAF or in the correct order. If you took such a project as datatypes, asks Ravi, would the SAEAF compliance come as a completely new set of deliverables or as an addendum. Mead says an addendum.
• Marc indicates it’s not just ‘what are CMETs’ but is this model compatible with that model and so cleaning up the materials already existing is another issue. McCay sees that as part of rolling out a product catalog, as we move forward picking products off that list and review them and revise them in light of the architecture. Koehn says the stakeholders have that worry.
• Mead agrees with Woody that message-specific project would not be necessary but good to expose the change management to organization.
• McCay says TSC should endorse SAEAF book production as well as EA IP, but are we uncomfortable with the role of the alpha projects to surface the impacts. Perhaps we want to take a position to say, yes, we want to materially impact the processes. Imagine the question in the stakeholders’ minds: Will the alpha projects sufficiently surface the impacts, or will you make it worse and more confusing? Pilot is a good idea, but have you produced a framework that allows an alpha project to move forward and screw up? What is the tool to resolve it?
• Koisch suggests that although those who are uncomfortable might be ok with being proved wrong, but need to have some discussion on how the impacts will be surfaced. Welcomes a meeting with Koisch and Woody and whomever over lunch and get the specific concerns and issues out on the table. McCay suggests that if there is another solution to surface the impacts besides leaving it to alpha projects; is that how the SAEAF book is endorsed? Koisch wants the TSC to say the ArB’s draft of SAEAF is positive imprimatur, need to move forward. Koehn suggests the issue is how to document the details of the uncertainty and doubt. Where are the surfaced issues to be documented and their resolution communicated?
• Mead suggests it has two levels of TSC position. He recommends the more assertive position be taken, sooner rather than later. Less assertive statement is that TSC says we think we are going to do this, will be a big changes, will impact what you do, but we’re going to do a pilot to prove it. The more assertive strategy is that we believe in the ArB, that the SAEAF is the next pathway for us, and the commitment to that pathway is an alpha project. If the alpha project fails we will do another one. If that fails, yet another one. This ‘’’is’’’ the path, the commitment. Koehn reiterates we use this assertive statement to say , we’re going into this to intentionally create change, with the intention to succeed, and will push certain projects to take on the mantle of an alpha project to avoid creating more legacy.
• ArB has committed to something, as committee constructed with representation by international architecture experience, to be credible with their recommendations.
• Woody brings up issue: should we do wrappers R2? Issue postponed to later in presentation.
• Returning to presentation: slide 13 decision processes and decision points.
• Three layers:
  1. framework (SAEAF)
     • top down framework
  2. HL7 Enterprise Architecture aka architecture #1 for HL7 (the blue box)
     • HL7 in total, everything we build, foundational documents, MDF, org chart, processes, whole business architecture – what we do, body politic, organization
     • stuff that’s produced by the framework,
     • foundational documents, core principles, RIM
  3. General health care enterprise architecture aka architecture #2
     • stuff built in the second ‘box’ used outside in the world
• Three things in play, people getting confused, making a picture for those boxes would be useful to helping people understand.
• Without reading 500 pages of SAEAF, how to understand what the changes are to the organization. Latch on to alpha projects, develop selection criteria. Came around to developing objectives for change. Hybrid model, develop for discussion the standards lifecycle as core framework of ‘’as-is’’ model
• McCay says we need to validate the list against output of org processes.
• People don’t understand objectives if we haven’t made our direction clear (Koehn). Mccay says if we fired off SAEAF work without such objectives clear we did a poor job. Lost institutional memory to outcome of strategic objective to refer back to those documents. Need to close back to original impetus, Hans stuff from ORC, T3F on the wiki. Who can link this back to the information back to them. Do we mean the Board initiative for Roadmap? Marc to work with John and Woody. We already got documents from ORC and Hans. ORC and RWJ process was validated – brainstorming by ea ip advisory group needs to connect to that for validation. Q3 Wednesday should say we’ve already agreed to move towards these objectives from ORC, RWJ, and align EA IP advisory group objectives with that set of accredited (?) endorsed (?) statements of objective.
• Slide 21: validate the standards lifecycle with TSC as notional process of how we make decisions with what we do. Mead suggests that change of focus from committee-focused to project-focused is objective. Koisch says focus of governance has been committees of good citizenship.
• product life cycle has been pretty well documented. SAEAF does not change that product definition, generation, and approval life cycle that McCay has seen. What he sees is challenge to how we approve set of foundational documents. Mead disagrees, with the example of the idea of CMETs versus the fact of CMETs. Current product definition/generation/approval is committee based; SAEAF is project based. Tremendous good citizenship goes into proiject teams across committee boundaries. SAEAF has fundamental product governance as project level rather than committee level.
• what are the roles of the various players within projects between committees. What does it mean in terms of who is accountable, where are the deliverables coming from what is level of transparency during build that suggests endorsement of level one, level two. Need assumptions about each step. Today it does this, this, this. Tomorrow what is that like?
• Koisch says HDF has six or seven use cases of how it is done. That thought has already happened. Need to take a step back and look at that material. SAEAF only impacts one of those use cases – a big one – developing a standard. What is surfacing is that HDF as project cycle needs to be pushed forward.
• Marc’s question is- what document of process is the one we should refer to for documenting as-is and to-be world to define the change? Is it in the HDF?
• Woody: complex process drives you to matrix world, not all-project, or all-committee. Example in Calvin’s Structured Documents committee, project within committee has divergent documentation. Can’t stop the entire org until we get all the CMETs built. Need to build up a project structure in the matrix but not getting rid of committees. Patient structure in Structured Documents does not look like a patient structure in Patient Administration committee.
• Project Life Cycle has subloops for informative/normative but otherwise project life cycle already done by Project Services – should this be driving approach for context of as-is and to-be. Process documents are in the HDF, aligned with the GOM.
• Foundational items RIM, SAEAF book, HDF, principles, localization: need to be coherent and consistent; we should as part of EA IP look at how to endorse and release (as compared to product endorsement and release). Mead says should be agnostic and apply to both product specification and foundational documents.
• Different requirements but can still follow process. PSC project lifecycle process does not incorporate process of maintaining the GOM? If you treat GOM as a project can follow same process. In project lifecycle they don’t use word for endorse – some other product-specific decision point. Maintain and enhance step on slide 21 is part of product step.
• Woody observes ‘coordinate’ is what all that other stuff is about, and occurs throughout the process. Enhance is same as initiate step in the cycle.
• McCay observes decision points made by committees now might need to change as project teams becomes decision making entities for product creation. What is different for foundational documents. RIM maintenance as an instance, SAEAF book maintenance will become another instance.
• Product lifecycle is based on a bunch of projects, says McCaslin. MnM says they don’t want to create separate project every January for same process. Whatever works for the RIM might work for the SAEAF book.
• PMI has process to do that per Ken that doesn’t break our process.
• Decision practices: what level of endorsement is required for SAEAF book as with RIM? How to initiate – that’s the PSS. Workgroup defines success criteria in the project plan, thus the level of endorsement.
• Koisch reminds that at Orlando he asked for projects to have rooms requested to devote resources.
• Will the TSC endorse SAEAF or is it balloted? How frequently do we expect endorsed releases of the SAEAF book – WGM cycle, annual, or as they become available. Prefer each WGM. Need to take issues and release each cycle? RIM is annual but is easier to reconcile, harmonization process allows for RIM to put out each WGM though balloted annually. May need two levels of endorsement process – WGM cycle harmonization but annual endorsement ballot.
• as we move from writing the saeaf book to implementing the saeaf book, harmonization may move from framework to specification. Each needs to be endorsed.
• Are alpha projects meant to slow down the churn in the SAEAF, asks Mead. What changes have to happen? Technical adjudication role of ArB.
• Ravi comments balloting EA specification as compared to SAEAF book.
• McCay suggests endorsement must be cognizant of tooling constraints on specification.
• Koehn says what additional endorsement is required in September if we make the strong assertion in Kyoto?
• Project lifecycle applied to foundational documents must be stable per cycle. Harmonization process per cycle as with RIM for other foundational documents. Realm localization, RIM and Core Principles? Merge process and technical definition or not? Core principles not going into SAEAF book? Parts of core principles talk about meaning of components of RIM.
• what are foundational documents, what is their journey over next six months, what is part of SAEAF book?
• could core principles be represented as a static framework along with behavioral framework another chapter, seventh section?
• need this discussion, whiteboard the foundational documents, what decisions does that drive?
• use the time on Sunday night. Need an answer for Monday night, certainly by Wednesday.
• Open question - Aggressive endorsement? Will CDA R3 deliverables be restructured to align with SAEAF? Aligning flagship projects? A CDA project, aligned with SAEAF, to use R3?
• Mead as ArB requests TSC take aggressive position for Wednesday presentation. High-priority projects must not go down the old road, but need to commit resources to those projects to provide SAEAF guidance.
• Calvin suggests Q1/Q2 sessions on Monday for Structured Documents are about CDA R3 startup. Plugging in at that point is opportune time.
• strong stance means? We’re committed to alpha projects and if we see problems we’ll make changes and move forward. The organization is committed to SAEAF just as we are committed to CDA R3 by 2010, it will be done SAEAF compliant. Strong message is based on strategic initiative, ORC,

Adjourn Q2 12:40pm.

Q3

1. Appointments to Nominations Committee: no further nominations were advanced.
2. Decision review since last WGM
   • Jim Case, for DESD, asks if many proposals are rejected. Generally felt that they are deferred for more information and eventually passed.
   • Ravi suggested a better display, perhaps by SD. McCay asked if we should have it for Monday’s presentation. Activity report for project approvals and publication – link to PSS or project page. Lynn to have that ready for Monday.
   • Discuss frequency of committee formation/dissolution; may change with implementation of SAEAF
   • Ravi would like to see statistic of how long projects take to reach approval. Lynn will try to generate that list.
3. TSC Project Review
   • Product list from wiki
   • Need column for third party products
   • CDA R1 and R2 listed separately; should they be? Is the differentiation helpful for those looking for implementation guidance. Drop version R1, use R2 per Calvin.
   • It’s about making the products visible, establishing process for defining list of projects; determining product set is Charlie/John’s task; TSC gatekeepers informed by marketing and production and publication.
   • Calvin indicates we need to have Clinical Statement as agnostic payload product; probably already on the list.
   • How do you propose new product? PSS more for support/enhance existing products. When a PSS for a new product comes through the TSC must recognize that and add to the inventory.
   • Education: associated with the products, or separate as Education services? Education summits as a service. E-Learning also a product
   • Products and services list, not just products.
   • Certifications? Is that a service? Also need to note on Resources if certification offered for particular product.
   • Need to centralize management of the information. Product/services, work groups, projects, link to each other.
   • Categories: tooling and modeling, process, (SAEAF, RIM), general reference tools
   • would like to see email alias for each product as contact. Not names for members in resources column… e.g. cdar2@hl7.org whether it goes to committee cochairs, listserv, hq, etc.
   • set up as RSS feed for if something new becomes available…
   • New HQ web designer will create structure to publish the info; Lynn collecting the content for now. Who will take responsibility?
   • process; Charlie’s list
     1. 1: Get a list of 10-20 top products
     2. 2: Draft a boilerplate product description
     3. 3: For each product identify 3 contributors and a wider review group (eg interested work groups)
     4. 4: Persuade 1 contributor to author a description, and the other 2 to review
     5. 5: Distribute to wider review list for comment (5 days)
     6. 6: post version on site
   • Koisch asks if this is related to Jane Curry’s product portfolio work? Really more for product visibility, not what we do, but what we have.
   • within v3 or cda need to drill down to messages and implementation guides where we get into bindings.
   • linking and dependencies between products, will need to be able to display.
   • will need to organize by parent-child relationships
   • simplify to 5 or six products and summaries links to product page
   • will need to ensure we have keywords from content providers, work groups for spiders to pull in from search engines
   • committees need to develop the business case, who would use this who is the intended audience
   • Product boilerplate, product brief template, needed. Product management group has been suggested; TSC is now taking ownership. Need template developed by marketing from outside perspective, not I.T. driven. Ken talked about the development of these concepts takes a specialized skill. Ken referred to Deidre’s work from the RWJ and will send info to Lynn.
   • Lynn to update project scope statement and bring it for approval.
   • question whether one waits until a product is released to begin marketing it, or start before it’s released.
4. Roadmap review
   • Charlie’s concern with strategies document around the TSC projects not being directly relevant to the roadmap.
     • Product and Project visibility is sort of a precursor or prerequisite to all of it. Should be the number one item of strategy number one.
     • Strategy 3.1 product overviews should be part of strategy 1.1, or make it ‘strategy zero’, for visibility of what HL7 is doing and producing.
     • comments field is opened on the roadmap page, so anyone can log in and drop comments in there. Even if TSC members should comment that I’ve looked at them
   • comments date for roadmap strategies V2.2 should be based on next revision and is currently end of 2020!
   • need to change Task to ID or Task ID on comments page
   • need to change TSC task 442 for Deliver a first TSC endorsed reference architecture document – we’ll talk about how it will be endorsed on Sunday night
   • review roadmap tasks: change ref arch document
   • review tasks: 411 Woody is not clear what it is supposed to be done? Major methodological changes anticipated due to anticipation of SAEAF impacts. Item 1 is being done, the RIM is under ballot. #2 is a tooling committee project for MIF vs UML and #3 is being addressed by the SAEAF book. Quinn says we should take the opportunity to use off the shelf tools when we can. Woody would like to close this, and McCay would like to see a one-pager on how or why MIF is the choice at this time. Tooling (assign to John Quinn, assisted by Woody) needs to write the one pager. As a Roadmap task it’s really being addressed with the EA IP.
   • carry over this item after break. Reconvene 3:30 pm.

Q4

1. review Monday agenda first, return to Roadmap tasks
2. Issue #457 discussion of workgroup meeting minutes recommendations, in reference to Skype thread on Datatypes R2 that became lengthy and should it be published. Should there be a recommendation to work groups regarding including Skype discussions on meeting minutes. Generally these discussions are either summarized in a meeting whose minutes are otherwise published or are vetted elsewhere. The resource, or knowledge capital, of the discussion thread that used to occur on the listserv is now off line. Listserv has archives that are publicly available as compared to skype archive. Suggest periodically taking the thread as an attachment to an email and send to the listserv, with dialogs routinely occurring involving three or more members. Ken will take it back to PIC to be updated.
3. Progress on work group Three-year plans: how often should it be? Should be updated between May and September so that for the new year has updated SWOT and three-year plans. Reiterate this for the Monday night meeting. Put on the agenda.
4. Three year plan and SWOTs become main page tabs on the work group web site; task to Electronic Services to review. Ken will take it back.
   • Monday agenda
   • Ken wants to be on the agenda, Electronic Services update. There will be a new release of the listserv to address some security issues.
5. Open issues review carry forward to Sunday night
6. Question on SDO meeting Sunday afternoon. Meeting will indeed be held, update from Edinburgh and a project update.
7. Tooling update
   • Since last WGM, Jane and Rick got cost estimates, dependencies and sequencing of requirements given to Don Simborg and Virginia Riehl as part of proposal to federal government as part of HL7 financing plan. Circulated by Jaffe to AHRQ, NCI, NLM, ONCHIT. ONCHIT folks were exiting leadership, new leadership not yet in place. John sent it to CTO of NHIN.
   • In addition to tooling funds there is a request to fund hiring paid staff within HL7 for facilitators so that SMEs and volunteers can act in that capacity. Would probably hire part time from among the volunteers that attend meetings now.
   • There is not a timeline in place for the tooling proposal; waiting for arrival of the new management of ONCHIT. New management will be in place next Friday.
   • Standards Advisory panel announced last night including Wes Rishel, Stan Huff, Dr Christopher Chute. John and Chuck have been in contact with John Glaser.
   • Tooling PPT pages reviewed by John Quinn and Woody.
     • would prefer to complete this process, de-legacy our current tools so that SAEAF implementation would not orphan legacy tools and artifacts.
     • current requests for funding do not include phases for SAEAF purposes
     • Does not include V2, CCOW, etc.
     • Is the tooling effort, also high priority by comparison to CDA R3, going to be SAEAF compliant? This has been in progress years already predating SAEAF or federal funding. Need to get off dependence on four or five people to manage the current tooling.
     • Discussion ensued on legacy artifact tooling, which development threads are relative.
     • Premise underlying diagram: intent in V3 was that all work would be in processable format so that files could be used for code generation as well as ballot generation. This has been in process since Baltimore 2002. How many of Frank's Access databases do we sell each year? Lynn to find out.
     • Alignment with SAEAF will require needs of the artifacts. SAEAF book - no tooling requirement, tooling project produces current and future balloting and user requirements; EA IP needs to track the relationship between the two. This may be a constraint on the EA IP that SAEAF needs to use these tools.
     • Quinn does not at this time know exactly what the specific alignment of the Tooling plan with SAEAF will be. McCay acknowledges both need to continue but alignment should occur before September.
     • Woody thinks McKenzie would be needed for this. It will need dedicated resources.
   • discussion to carry to Sunday pending Woody’s availability due to conflict with MnM. Koisch indicated they’re having a working a lunch on Monday if anyone’s interested on wrappers. He suggests another lunch on Wednesday?
   • Action item into EA IP discussion Sunday night to clarify role with alignment with Tooling plan.

Adjourned 5:12PM local time