2010-10-03 TSC WGM Minutes

TSC Sunday evening meeting for 2010Oct WGM

back to TSC Minutes and Agendas

TSC WGM Agenda/Minutes

HL7 TSC Meeting Minutes Location:		Date: 2010-10-03 Time: Q5 7 pm to 9 pm dinner is not included
Facilitator	Charlie McCay	Note taker(s)	Lynn Laakso
Attendee	Name	Affiliation	Email Address
x	Calvin Beebe	HL7 SSD SD Co-Chair	cbeebe@mayo.edu
x	Woody Beeler	HL7 FTSD Co-Chair	woody@beelers.com
x	Austin Kreisler	HL7 DESD Co-Chair	austin.j.kreisler@saic.com
x	Lynn Laakso (scribe, non-voting)	HL7 HQ	lynn@hl7.org
x	Ken McCaslin	HL7 TSS SD Co-Chair	Kenneth.H.McCaslin@QuestDiagnostics.com
x	Charlie McCay (chair)	HL7 TSC Chair	charlie@ramseysystems.co.uk
x	Charlie Mead	HL7 ArB	meadch@mail.nih.gov
regrets	Ravi Natarajan	HL7 Affiliate	Ravi.Natarajan@nhs.net
	Ron Parker	HL7 ArB Alternate	rparker@infoway-inforoute.ca
x	John Quinn	HL7 CTO	jquinn@hl7.org
x	Gregg Seppala	HL7 SSD SD Co-chair	gregg.seppala@va.gov
regrets	Helen Stevens	HL7 TSS SD Co Chair	helen.stevens@shaw.ca
x	Ed Tripp	HL7 DESD Co-Chair	Edward.tripp@estripp.com
x	D. Mead Walker	HL7 FTSD Co-Chair	dmead@comcast.net
x	Steve Hufnagel	guest, Government Projects, US VA DOD
x	Rene Spronk	guest, RIMBAA Co-Chair, HL7 NL
x	Jane Curry	ArB, Tooling
Quorum Requirements (Co-chair +5 with 2 SD Reps) Met: yes

Agenda Topics

1. Roll Call and Introduction of visitors (including declaration of interests)
2. Additions to, and acceptance of, agenda:
3. EA IP (15 mins) - assessment of current state, and put it to bed
4. Scope/ risk assessment /value proposition for new SAIF project(75 mins)
5. Subsequent message and agenda setting (30 mins)

Minutes/Conclusions Reached:

1. Visitors:
2. Additions to, and acceptance of, agenda:
3. EA IP (15 mins) - assessment of current state, and put it to bed
4. Scope/ risk assessment /value proposition for new SAIF project (75 mins)
   • Have we got a value proposition for adopting this architecture framework?
   • Original intent was to obtain an architecture… what we’ve got is an architecture framework.
   • Still have the original problem in ensuring consistency.
   • WB thinks keep it to V3. Need to define architecture in which alignment can occur.
   • Notion of consistency, says Charlie Mead (CMd), is about explicitness. Chose MDA and RM-ODP because they thought people were familiar. Guidelines for compatibility left those in the silos still building non-interoperable work. Need to define the scope, sit down and do it, then put some teeth into it.
   • Governance has been already implemented with harmonization as well as balloting, even Work Group Health with explicitness of measures. The idea of “teeth” to a governance process is off-putting. The scenario calling for such action is unusual, when someone tries to get something through behind the scenes for example.
   • Prior projects selected were focused on developing their own products, not in fleshing out the architecture. When we developed this project we didn’t yet know it was a framework being built; thought we’d have an architecture. CMd brings lessons learned which we didn’t have at the time. He feels we should address specifically the interoperability first and then allow the architecture to evolve from it.
   • Once again to define the problem facing HL7 that SAIF is trying to solve, what is the highest value area in which we can make progress.
   • Woody cites three related sets of questions: we’ve never had a behavioral structure that satisfied basic needs of placing orders from a lab. Distinction between clinical documents and messaging have fuzzy definitions of messaging – what is the nature of behavior within them. How to deal with information structures in common concepts? Mead reiterates we need to pick one problem and solve it, but adds delivering and understanding how developers of functional models work with developers of information structures.
   • Calvin adds to relationship of behavioral aspects between msgs and documents, a technical aspect of constraint developments and on artifacts; architecture needs to be more flexible to accommodate that.
   • CMy recounts on whiteboard:
     1. Alignment across interoperability paradigms - Messages/ Documents/ Services – especially static content
     2. Behavior
     3. Common Representation of Clinical Structures
     4. Functional Model / Information Models
   • Two questions to ask against each – how big a problem is it, and how value would be added to HL7 and its stakeholders (can SAIF solve it)? CMd says – state what the problem is first, then determine how you solve the problem.
   • Woody says three years ago in forming the TSC people wanted a coherent architecture, to solve these same problems, which we have not yet solved.
   • Why do we care? Austin notes he’s got a representation of a lab result in a CDA that doesn’t work with the representation with a message. He wants to take a template and apply it to both so that the representation is the same.
   • Woody notes the issue about a standard for ICSR that should be independent of whether it’s sent by message, document or service for submission. Also we are 10 years into V3 and we still don’t have basic labs? Partly the behavioral framework issue (we have results but not orders).
   • Do we pick just one of the list to solve or distribute the request to work on them across different groups? The Behavior, Common Representation of Clinical Structures, and Alignment across IP with static content are already in progress. Mead says there’s a benefit in picking one thing to fix is that we can actually fix something specific to show we’re doing something. Risk with multiple focuses is it’s too hard to manage.
   • Charlie McCay (CMy) asks instead, which one are we NOT going to do any work on. CMd says scope at a different level, pick CDA R3 or another high-profile project and note what working on that impacts on different levels. Woody feels CDA R3 is an infrastructure, different kind of product and needs to be made consistent with other paradigms.
   • CMy suggests Lab Composite Order, versus CDA R3, versus EHR FM. CMd says to make those three work then they also need to have MnM, ITS involved. Need to get these guys out of their silos and have them work together.
   • Woody notes that EHR FM greatly increases the scope. Aligning messaging/SOA/CDA issues is one challenge. CMd argues that the EHR S FM also represents the same set of problems.
   • Need to change the unofficial idea that there are some problems that can’t be solved by documents. Need a specific example.
   • What metrics will be used to measure whether we’re making progress. What scope shall be used to define the candidate projects.
   • Calvin says we need to create problem definitions from the problem list. Get people to agree on what is the problem. It would be hoped someone would come forward to address the problems. First Identify the problems, then have a quality control cycle to come back for agreeing on the problems, then we’ll look at addressing the problems through the lenses of our SAIF perspectives.
   • CMd says you have to be careful about what you go out and ask the general membership about what they think the problem is. Calvin wants key people who have perspectives on the problems to participate in the problem definition, not to send it out to the general membership.
   • CMy said when we started with project scope statements, folk would throw tomatoes during the cochair meeting such as was met with some resistance but have now recognized it’s worthwhile. More structure to their projects they will fight against.
   • Austin says make a big silo out of CDA, Orders, and Functional Models, to work together to make the rules by which they can all play. Others will see value to join that silo, and it will become the enterprise.
   • Three strands of activity happening concurrently. If we have a single project we focus on and be seen having success in that space and creating the pieces to support that process.
5. Subsequent message and agenda setting (30 mins)
6. Charlie recaps. There is a value proposition, around addressing the four points listed above as problems. Talking about scope, risk, change management, and artifact definition.
   • Candidate scope of CDA, Orders, Functional Models.
   • Woody asks if terminology binding is as big a problem as these others? It will emerge later showing up in the information viewpoint.
   • Artifacts to deliver this? CMd says Implementation Guide, lots of ‘static side’ artifacts. Candidate behavioral artifacts from the NCI, Functional model profile, Austin’s group work on the behavioral model. HL7 reference documentation suite needs to include a definition of the artifacts. CMd notes you can’t only work top-down because you risk specifying something that is not implementable. What about prototyping that shows the viability of what we’re doing.
   • CMy notes we’ll state we need to specify some artifacts, CMd notes that we should indicate we’ll look at them top down and bottom-up but don’t specify where the bottom is…
   • Calvin states Architecture has to have components and have relationships between components. Woody asks what about meta-models? Research and Mine artifacts being generated in the three interoperability paradigms to understand how they’re put together and how generated from current processes and mechanisms. HL7 deals with many levels of specifications.
   • Woody asks what progress have we made since 1996 to define what templates are and how they fit in.
   • CMy notes we can say we need to identify some artifacts, and might not yet say what they are yet.
   • Risk – CMd says go back to the problem you’re trying to solve… what comes out the other end. We have some governance already, project approval, and we have ballot at the end. Austin adds we have governance through the RIM and conformance to it. CMd then asks where else do we need to govern? Calvin says that’s the last question we ask, because we must first address the problem and then define the architecture, then you answer the question as you operationalize it.
   • Ed asks is the risk if we don’t successfully solve the problem? CMd says it’s also about the checks and balances, and how you operationalize the architecture. Risk is if we don’t employ the appropriate governance at the right point. Woody and Austin note that the publishing process adds its own governance as the tooling requires a certain conformance.
   • Change management, need to identify current architecture and traceability to the changes needed though to the new architecture. Ed says you need to get people to understand the value of the change perspective. Traceability of what we’re trying to change back to the problems you’re trying to solve, says Calvin. Ed says you must also personalize to the audience.
   • Monday night, present list of issues, remind everyone why we wanted and architecture, remind we have an architecture framework. Looking for focused area to demonstrate benefit across that list of problems. Suggest to be less explicit about the scope to say messages, documents, and Functional Models not specific projects.
   • John reminds the cochairs dinner has only very short time slots to present.
   • Weds Q4 – most Work groups have rebooked time using that slot. OO Behavioral Model is meeting with MnM already in that quarter. Calvin will try to attend.

1. Adjourned 9:07 PM

Actions (Include Owner, Action Item, and due date) .

Next Meeting/Preliminary Agenda Items .