2009-02-24 EA IP Advisory Group Call Minutes

TSC EA IP Advisory Group

Tuesday, February 24, 2009 at 3 PM EST (US Eastern Time, GMT -5)
To participate, dial 770-657-9270 and enter pass code 124466#
GoToMeeting at https://www.gotomeeting.com/join/563682304
GoToMeeting ID: 563-682-304

back to EA IP Meeting Agenda and Minutes

Agenda

• Meeting Goal: To provide an initial grounding for the group and to assess Alpha Project engagement approach

1. Introductions
   • Chair: Marc Koehn (Marc.Koehn@GPInformatics.com)
   • HQ: Lynn Laakso - scribe (lynn@hl7.org)
   • Ed Tripp (edward.tripp@estripp.com)
   • Galen Mulrooney (Galen.Mulrooney@va.gov)
   • Igor Sirkovich (Igor.Sirkovich@Ontario.ca)
   • Jim McCain (james.mccain@va.gov)
   • John S. Carter (jcarter@apelon.com)
   • Ken Rubin (ken.rubin@eds.com)
   • Lloyd McKenzie (lloyd@lmckenzie.com)
   • Nancy Orvis (nancy.orvis@tma.osd.mil)
2. “Brief” Review of HL7 EA-IP Phase 1 Summary Deck [1] Please review prior to call and recap of current Project team activities
   • Need also to embark on some implementation activities to maintain momentum during Phase 1 planning into Phase 2 Implementation
   • Considerations: responsibility and interdependency definition is the work of this Advisory Group
   • Alpha projects as key instrument to drive planning forward
     • How does one get approval to do alpha project? Some have been turned down already… What are the criteria? A: Will be covered later on the agenda
     • Jim: process would benefit from alpha projects that define and move things forward
     • Lloyd asks if we have any conversions, taking existing suite of artifacts and aligning them to be consistent with SAEAF? Ed says we should have one like that to shake out Business Architecture with different rules than for a new project.
     • How many can we support? What is the principle of engagement, to take materials from their output to shape our processes?
     • Ken: Business Architecture (BA) can be two different things: understanding needs of community, capture them, use alpha projects to gain understanding of requirements. Second – organizational adoption of arch and what it means to committees. Former or latter or both? Both need to be done. How do we get there from here? Which side of th fence are each of these on. Constraints on the architecture versus how it gets used. For eample HITSP wants us to do ‘x’; CHI wants something else, etc – that’s a requirement for the architecture. SAEAF and EAS says we’ll make DAMs, do we extend the HDF to include this requirement and this is how we roll this out. Very different streams of work. Need to be on guard to capture techniques to address both. Consider during alpha project deliberation. *Risk*: Will the alpha projects be reflective of the set of requirements that the industry has out there?
3. Review of Group Purpose / Objectives: To advise and assist in the development of deliverables for the HL7 EA-IP Project (Phase 1)
4. Alpha Project engagement approach (See below) – Discussion questions:
   • Any initial thoughts re. selection criteria?
     • How and why are we selecting a project?
     • What are the rules of engagement? What special services do they receive, what do we expect from them?
     • Ed voices concern of group ability to maintain support for more than three or four projects, one being a conversion of existing materials, one a new project.
     • Lloyd: At least one must tackle an area difficult in existing methodology;
     • For example, stitch together entire process flow/dynamic model for an area like laboratory.
     • Ken suggests defining success criteria and working backwards: Three paradigms in SAEAF (documents, messages and services); must cover that spectrum.
     • Nancy says as with NHIN demonstrations last year, what would we like to see it demonstrate. Marc asks if this means it should span two areas? (i.e. ideal project deals with more than one paradigm)
     • Ken ? committees want to start with single DAM and be able to generate CDA template, V3 message spec, and services payload spec. Besides the matter of tooling, can the architecture support that effort? Need to show how does HL7 control and master the domain of healthcare information in and out of HER (Nancy). (?) show V2 going into CDA type V3, payload into messaging service. U.S. limited V3 adoption. Must show how to get to V3 from V2 for relevance in U.S. Ed indicates RCRIM uses it more extensively.
     • Are these projects creating standards, or creating systems? Thought we were creating standards… this is a little of both. Complexity spanning versions; is this a system or standard? SAEAF is about creating a specification. To go a step further one would implement the specification. Driver is creation of specification and can be evaluated by an implementation but is not criteria for success. Criteria is whether the specification can be generated. However if you don’t show the specification out to the implementation it risks not being implementable. Criteria for effort to create spec, review spec, did implementers find it easy to understand, more usable information than with more typical artifacts. Do we need a baseline – what this looked like using old methodology and what it looks like using new methodology…?
     • Not that every project go through an implementation… but at least one should.
     • One element of analysis is whether the alpha project is that they want to build a spec versus a dimension of implementation, dimension across types messaging – services, etc.
     • Among the four, at least one does conversion, at least one goes to implementation; must cover a certain breadth.
   • Any initial thoughts pertaining to anticipated engagement issues, principles, etc.?
5. Brief review of Initial streams ...
   • Decision framework
   • Communication plan
6. Next steps
   • John Carter: do we need pre-alpha project to conceptualize what this would create; identify, with an existing example, the characteristics we need?
   • Take some criteria we’re coming up with, elaborate into a worksheet, take a project to test worksheet against, and put the worksheet out there for projects to use for self-selection. Marc indicates we also need to identify our expectations for them as well. John indicates we can better elaborate that set of rules by comparing them against a concrete example versus an abstraction.
   • Ken thinks too soon to reach out to alpha projects if we don’t know what we want them to do.
   • Nancy reminds we also need to work on Business Architecture.
   • Marc says we’ll create a page on wiki for straw man of success criteria, principles of engagement; group to review and enrich. Next call to be: how do we engage them and when, what parts of the architecture needs to be evolved before we reach out to them. Goal for next meeting 80% comfort with parameters, 70% of selection criteria. Next meeting aim for 90 minutes.

“Alpha Project” Launch:

1. Schedule fact gathering conference call (2 – 3 hours) to initiate dialog with candidate alpha projects
2. Proposed agenda and call to action including:
   • Introduction & purpose of call (namely Information exchange and grounding) – 15 minutes
   • SAEAF Overview (ideally through an ArB member) – 30 minutes
   • Alpha Project Synopsis: Each project to give a 15 min. presentation outlining: who the sponsor agency is; the nature of the project; how they hope to leverage the SAEAF; and what their ultimate goals are in participating (e.g. balloting of a particular spec).
   • Next Steps – EA-IP Team to outline anticipated next steps re. Alpha project criteria development and to identify next contact point
3. Subsequent to the call, Project Team and Advisory Group to determine criteria and terms of engagement in collaboration with the ArB.

Recommended Pre-Reading:

• SAEAF Document and associated ArB materials (although detailed content knowledge is NOT a pre-requisite): These materials can be accessed at the following URL: [2]
• DRAFT HL7 EA-IP Phase 1 Summary Deck