2009-09-20 TSC WGM Minutes

TSC Sunday Dinner/Meeting for September 2009 WGM

back to TSC Minutes and Agendas

Sunday September 20, 6-8PM Q5

Charlie McCay called the meeting to order at 6:10 PM

Apologies

• Ken McCaslin

Roll Call:

At	Name	Affiliation	Email Address
x	Calvin Beebe	HL7 SSD SD	cbeebe@mayo.edu
x	Woody Beeler	HL7 FTSD	woody@beelers.com
x	Bill Braithwaite	Anakam Inc.	bbraithwaite@anakam.com
x	Richard Dixon-Hughes	HL7 Advisory Council	richard@dh4.com.au
x	Marc Koehn	HL7 EA IP PM	marc.koehn@gpinformatics.com
x	Austin Kreisler	HL7 DESD	austin.j.kreisler@saic.com
x	Lynn Laakso (scribe)	HL7 HQ	lynn@hl7.org
x	Patrick Loyd	Gordon Point Informatics	Patrick.Loyd@gpinformatics.com
x	Cecil Lynch	OntoReason, LLC	clynch@ontoreason.com
	Ken McCaslin	HL7 TSS SD	Kenneth.H.McCaslin@QuestDiagnostics.com
x	Charlie McCay (chair)	HL7 TSC Chair	charlie@ramseysystems.co.uk
x (governance discussion)	Charlie Mead	HL7 ArB	Charlie.mead@booz.com
x	Galen Mulrooney	US Veterans’ Affairs, SOA WG	galen.mulrooney@va.gov
x	Ravi Natarajan	HL7 Affiliate	Ravi.Natarajan@nhs.net
x	John Quinn	HL7 CTO	jquinn@hl7.org
x	Gregg Seppala	HL7 SSD SD	gregg.seppala@va.gov
x	Ioana Singureanu	HL7 FTSD	ioana@eversolve.com
	Helen Stevens Love	HL7 TSS SD	helen.stevens@shaw.ca
x	Ed Tripp	HL7 DESD	Edward.tripp@estripp.com

• Additions to agenda:
  • Update on the CTS2 approvals
  • Update on DCM by Charlie McCay
  • Update on CTS2 work - Woody
• Agenda
  • Old business notes
    • CTS2 ballot reconciliation voting on disposition of comments does not meet Vocab quorum requirements. Email sent back to Russ to notify.
    • DCM: Charlie McCay met with William and he is working on rewriting the project scope statement to address our concerns on DCM.
    • Woody reports in an email from Lloyd McKenzie to the Charlies after the OOC meeting, CTS2 issue; McCay rang up Lloyd and Jobst about their goals, separating generic concerns about HSSP process, how we hand off specifications to OMG. Particular concern around HL7 producing a functional requirement, where it becomes an OMG specification and the process ends there, with a cobadged HSSP spec based on an HL7 DSTU. Charlie thinks the TSC needs to understand how that process works, what happens when the DSTU expires. Ioana has an understanding that DSTU does expire, implementers provide feedback. With feedback from the OMG responders the HL7 DSTU can become a normative specification. Galen adds that OMG has a finalization process, after an interim release specification. He adds the bifurcation of process between HL7 and OMG is to protect HL7 IP rights because OMG products are free to the world. Process is not perfect, but can be revisited, especially now that we’ve had experience on two specifications, particularly with the feedback loop, and reference to the reference profile. Woody recounts that Lloyd makes no mention of a subsequent ballot. Cecil adds that if he wrote that email now, most recently, it would come out very different. The details necessary to represent HL7’s concerns are not in the DSTU. Ravi asks if there is documentation on the process now, and Ioana says it’s in the HDF and Galen adds it’s also on HSSP. Galen willing to take an action item to have a two-month project to revise the process with Richard Soley and the TSC (or MnM or whoever we wish) to address. Ioana says it should be joint project with MnM as this is a methodology issue. McCay says we need to be clear what the concerns are we’re trying to address. Mead says it’s a governance and process issue. Charlie McCay directs discussion to table.
  • EA IP Status
    • Charlie Mead present on what NCI is doing for governance (5 mins)
      • If you want the EA strategy to work you’ve got to have governance.
      • What are you governing? ArB trying to build SEAF framework in such a way that the artifacts that focus on interoperability are the only that they worry about (as compared to NCI). Appears to work if there is a group dedicated to doing governance, and that only works if you have resources involved. They have governance councils set up around RM-ODP viewpoints, business enterprise e.g. clinical sciences and xyz sciences domains. 2 people for each viewpoint. HL7 may not care about the technology viewpoint (ITS? May be engineering viewpoint). Set of defined templates, (artifacts that have to be produced by project teams) that has to be passed through governance council before going forward. Inception elaboration and other phases are observed to avoid vertical blinders. Interoperability is a first class citizen. Governance teams, around viewpoints, defined templates, and enforcement. Governance needs to sit further upstream than ballot. Project Scope Statement is the only template we have, Cecil adds. Mead adds that the templates are only for services specifications, not messages or documents. Ravi suggests that we should have a risk log with the SAEAF project. Does HL7 require proper project management of its projects, following standard practices. Ioana says the only governance now is the publishing schedule, and there are not other governance points besides voting negative on a ballot. McCay said that a year ago we started on a quality project to identify the preballot checks that should be done against a standard to prevent documents of insufficient quality from going to ballot. What happened was that a bit of work was done on a checklist and then it ran out of steam. Marc says there are many little details, e.g. checklists and templates, and so on we have to change what we have now to improve it; we struggled with how to pull the elephant apart. Need detailed principles of what this is supposed to do. We hare committed to governance, which means content, process, and structure governance. Cecil agrees with Marc that it’s so big, even to talk about it abstractly is hard, and concretely, where do we start? Maybe in Domain Analysis Models, a concrete artifact that has slipped into the ballot process without any constraints on what its supposed to look like. Mead Walker threw it out of what is a DAM. Are they normative or informative? Informative because we have no requirements around what would make it normative. Ioana says domain conceptual models are something that needs to be addressed: (e.g. is DIM same as platform specific model), to address the HDF to bring it in line with the SAEAF. Patrick recounts what Ioana said earlier that it’s a volunteer organization and makes that difficult. What are the requirements to make a conceptual model. Marc says all our core artifacts need an alignment path not just the HDF. But what are the principles to move into this direction. Funders and “voluntolds” need to address it to. Patrick says the first balloted DAM took a larger context area and boiled it down to just one condition: TB. Ioana says we have a project life cycle that we don’t follow. Patrick says many committees regard V2 as their ‘informal’ DAM. Ed adds there are some groups in DESD that think they don’t need a DAM. Marc asks do we have a list of activities, re-educate on DAM, revise the HDF, but this does not give us what it means to have governance in an active, early way. Can this group agree on what this should be? McCay asks since 5 years ago the strategic review that a coherent approach to the three paradigms was of concern, and after the T3F, TSC, ArB, and Board initiative – still a top priority issue, could we say, resolving that issue is such a priority and require that implementation projects don’t ballot unless they address that issue within a timeframe. 12 months from now no project goes to ballot unless it addresses that framework. Ioana recounts that the Project Life Cycle (PLC) says the first thing you do is an analysis but you can go to ballot without having done analysis at all. Is this just an informative guideline? McCay says that is a decision the TSC is charged with making, just as we are charged to roll out the EA. Ioana says we are great at the project initiation stage, but the TSC should get into the other stages of development. McCay states the EA IP and project management rollout are an exercise in implementing change in the organization. The T3F didn’t feel empowered to do so, and now the TSC. Now we can get them to tell us what the projects are. Now we are in a position to do more change, but that change must be prioritized. Where do we need to make those changes happen. Marc observes, given this, who do they write their stuff, second, did they follow the rules, and third, is it cohesive? Are we prepared to establish gates, outline what those gates will do, and resource them accordingly. Calvin adds, he took the SAEAF training as Structured Documents approaching an important product and approaching a chasm with no tools, no structure, just boxes on a grid. And it feels as though we will just get beat up as we go along by governance. Woody feels that we’re overlooking the internal governance and quality control within a committee, and that external quality points are not the issue. Ed adds that we do need some framework around the 12 boxes of the abyss like a checklist of things they have to produce or address but I don’t see us having the resources of having two people each looking at this perspective. Ravi asks what happens if the alpha projects fail? If the project fails, we can still learn from the projects and go back to the ArB and learn from wrong decisions. Patrick echoes Calvin’s sentiment, but not every project in the next 12 months can be an alpha project – there is not enough resource on the ArB to be part of the process. Many projects will have to continue their current path. Can’t halt progress on other existing projects. Rumor that anyone working on common content is going to have to halt and wait for SAEAF.
      • Woody agrees with Ravi that the chasm with 12 boxes doesn’t mean you have to fill them all in. We have some good tools, for RIM-defined models for example but we don’t have tools for everything, no. We’ll have to adopt the same strategy and develop as we go along.
      • Marc agrees we won’t get everything right. We now have momentum and we have to stand behind that. TSC needs to decide if quality management will be bottom-up or side in, or top down. If someone feels they’re being beaten up then we haven’t communicated the goals to reach a new objective. This committee needs to state those goals. Instantiate it in the steering divisions, in one or two committees. We don’t know what those are and who agrees to them as we don’t have consensus.
      • Cecil: the ‘beating up’ is what we all do in every committee when we evaluate what we balloted the last time and develop a next release. We’re talking to try and find a place to start, put another gate in. we have no way to tell a committee what a good conceptual model is. How do we tell them how to capture the detailed information to produce useful specifications that are cohesive at the end of the road. We’ve said they should have a conceptual view, is that using HL7 datatypes, or is it abstract datatypes? Ioana says chapter 3 of HDF says how to create a domain analysis model and what should be in a DAM. TSC mature enough to exercise governance on enforcing creation of DAM. Cecil clarifies we need to tell them what they cannot have not just what they can have. Woody does not want to force everyone to do a DAM; eMeasures is a great example and doesn’t need a DAM. Three gates: one to agree to attempt to follow the 12 boxes, two and come back that boxes are filled in or what, and third do we want to ballot it. We can’t find ways to beat people up when we don’t give them the tools to produce it. Charlie McCay does not wish to celebrate the TSC’s ability to exert some governance, although the TSC has had a hand in the approval for projects in the Project Life Cycle. There are checkpoints on the ballot process, reconciliation in particular. TSC has limited, though substantial, power and influence so we must wield it carefully for our stakeholders. Patrick notes Keith identified six areas that do lab, but that is supposedly something HL7 does well. Woody clarifies that we should just start, and create the quality measures as we go along. Galen comments that the HSSP project did well at a rule that said here is the boilerplate for the SFM, and when you start you must use the version that was current at the time. If you started a project earlier you are not required to comply to the newer version but you have the option. We could start defining buckets, where new projects have to meet those items. Galen agrees the governance has to be within the committees, but the TSC needs to define the methodology and artifacts that a project has to do, and the projects or WG can govern themselves with how they adhere to those. Ed suggests we lay our existing artifacts into the buckets, and work on what needs to be added to make it fit into the SAEAF framework and define what the benefit is to make that fit. This is what this brings, we haven’t defined it yet, but this is the benefit of having it. Calvin is pleased with the discussion. Structured Documents is excited at the challenge. They want to play by the new rules, want to help ArB partners understand what static documents are and how they get on the messages train or services truck. We have existing tools for getting things out. The tone of communication should be conveyed to avoid appearing heavy-handed. Patrick says they know not everyone will be able to exercise all 12 boxes well due to the different paradigms. It is not expected that everyone will come with a full set of all 12 boxes. Marc asks how far do we push change or do we meander forward. Need to remember the reason for those 12 boxes, that different stakeholders have different take on those viewpoints. Need to expose the possibility that there are opportunities to surface other considerations that we haven’t seen yet. Ioana says we want to engage clinicians, so must expose them to content at a level appropriate for subject matter experts. Java and XML or something appropriate to clinicians? Do we really want to engage a wide variety of stakeholders or do we only want to work with those that can communicate with us at our level?
      • Woody asks Marc if there is one checkpoint that stands out common to the continuum, is there an obvious core checkpoint? What does it take to be the gatekeeper when we can’t get funds to send harmonization resources but want to add gatekeepers? Marc says we should jump in and allow the alpha projects to identify the things that cross the various projects. Ed also recommends other than regarding it as phase gate but as periodic peer reviews and leverage the Steering Division for peer review. Calvin says the CMETs or predefined milestones haven’t been defined yet. A Pioneering effort is being asked of these groups but we don’t know where the checkpoints are. McCay indicates we may have consensus that not every project can be a SAEAF project, that’s how existing projects will tie into SAEAF work, a limited activity with the whole Working Group. Want to advance artifacts or information as soon as possible so other projects can begin to follow. We have a process for other checkpoints beyond the ballot, with Project approval, NIB. We could introduce additional checks around the Lorenzi proposal 6 months ago. Patrick has a suggested approach: ArB facilitators per project could be tasked to look at the governance aspect during the alpha projects, and by the end of the alpha projects they would have recommendations on the checkpoints. TSC’s job to do the governance but Cecil observes that the ArB could still identify the places where governance is needed. Bill adds that this is a different type than top-down day job governance but instead the governance comes from within the Work Group. Woody says we shouldn’t use the word governance and just call it peer control. McCay says the TSC has been using the word Visibility and not “Control”. Share what you’re doing expose what’s happening, make visible. EA IP can do the same.
      • Calvin agrees that since we’re having ArB assistance we have ArB ideas on where we need governance. Also should ask the committees participating in the process to recommend governance or peer review points. McCay says the Arb should be, as they are working with the alpha project groups to use visibility, peer review communications instead of governance. Quinn indicates that governance comes from the RM-ODP in the building of software under SOA architecture as compared to how we build standards. Cecil suggests we change it to ‘meaningful use’. Marc cautions against using words that don’t communicate what we’re doing; quality reviews to ensure that the products conform to a cross-platform principles cross-model consistency, that need to be enunciated up front. We should not sweet-talk something we’re trying to change. Austin says we have an example of clinical statement in governance and peer review of models. They have a process for those groups using clinical models to change clinical statement, has evolved over the past 4 or 5 years. Common product model is beginning to adopt a similar approach. Can build on patterns already doing what we’re trying to do under SAEAF. Woody says we should mine the collective wisdom of patterns of things, what exactly are the six examples of lab models. Judge them later on, but identify where they all are… Marc asks if he and Woody can discuss offline. Learning from the projects is a key part of the EA IP and we need to identify how we cull those learnings from the projects on a regular basis.
      • Marc asked for next steps. Now that projects have launched how do we gather information from it. Roll out SAEAF, roll out governance or peer review quality criteria, bring back the learnings, and provide communication.
      • McCay says urgent messages are: if you’re alpha you get the support of ArB facilitator. Not expecting you to stop if you’re not an alpha project, the show must go on. We’re doing good stuff we don’t want to stop but we still want to work on improvement. Another message is to address the HSSP issues and remember Galen’s offer to facilitate that process. Third, what are the benefits that we’re trying to get out of the implementation and architecture process.

Adjourned at 8:01pm.