2011-05-14 TSC WGM Minutes

From HL7 TSC
Revision as of 17:35, 14 May 2011 by Llaakso (talk | contribs)
Jump to navigation Jump to search

TSC Saturday meeting for 2011May WGM

back to TSC Minutes and Agendas

TSC WGM Agenda/Minutes

HL7 TSC Meeting Minutes

Location: Orlando (Lake Buena Vista) FL, USA

Date: 2011-05-14
Time: 9:00am - 5:00pm EDT)
Facilitator: Austin Kreisler Note taker(s): Lynn Laakso
Attendee Name Affiliation
x Calvin Beebe HL7 SSD SD Co-Chair
x Woody Beeler HL7 FTSD Co-Chair
x Bob Dolin HL7 Board Chair (member ex officio w/vote)
x Chuck Jaffe HL7 CEO (member ex officio w/o vote)
x Tony Julian HL7 FTSD Co-Chair
x Austin Kreisler (Chair) HL7 TSC Chair, DESD Co-Chair
x Lynn Laakso (scribe, non-voting) HL7 HQ
x Patrick Loyd HL7 T3SD Co-Chair
Regrets Ken McCaslin HL7 TSS SD Co-Chair
x Charlie Mead HL7 ArB Chair
Don Mon HL7 Board Chair-elect (member ex officio w/o vote)
regrets Ravi Natarajan HL7 Affiliate Representative
x Ron Parker HL7 ArB Alternate
x John Quinn HL7 CTO (TSC member ex officio w/vote)
x Gregg Seppala HL7 SSD SD Co-Chair
x Ed Tripp HL7 DESD Co-Chair
regrets Jay Zimmerman HL7 Affiliate Representative
x Jane Curry Tooling WG cochair
x Grahame Grieve
Quorum Requirements (Co-chair +5 with 2 SD Reps) Met: (yes/No)

Agenda Topics

Q1 - Roadmap and HL7 Strategic Issues: 9 am to 10:30 am

  1. Roll Call and Introduction of visitors (including declaration of interests)
  2. Additions to, and acceptance of, agenda:
  3. Link to Interim decision review since last WGM
  4. Strategic Initiatives discussion
    • HL7 and IHTSDO - Closer Cooperation (30 minutes, Bob Dolin)
    • HL7 Quality Plan
    • Product Strategy - The missing strategic initiative
      • granularity in level of balloting, topic-level ballots or product briefs versus domain level (Product Strategy)
  5. Request for TSC to develop guidelines on what should be Informative vs. DSTU vs. Normative, at TSC Tracker # 1815
  6. Need for statement on what V3 includes (it's not just V3 Messaging) like RIM, Datatypes, 21090, CDA, are all part of V3 - Charlie Mead.
  7. Suggested rules for TSC intervention and audit of aging standards projects


Q2 - Architecture and Tooling: 11 am to 12:30 pm

  1. SAIF Architecture Program at Project Insight ID# 751
  2. Tooling Update
    • Tooling update by John Quinn
    • Sparx Enterprise Architect license management - see document


Q3 - TSC Planning and Open Issue Review : 1:30 pm to 3 pm

  1. (45 mins) Review Open Issues List
    • HL7 Security Considerations - Cookbook: Austin, at TSC Tracker # 1513,
      Status as of 2011Jan WGM: what is the consensus mechanism by which this has been approved for use as an Education tutorial?
    • How to proceed with NCPDP’s request for mapping to the RIM: John, at TSC Tracker # 1647
      Status: Update from 2011Jan WGM: John had sent something to them. No response for 5 or 6 weeks. Don Mon has been conversing with NCPDP on SCO. Future of SCO to be discussed.
    • Explore maintaining usage statistics for V3 (pending response by Marketing): Austin, at TSC Tracker # 1661
      Status: No response from Marketing; suggest referring to business model task force?
    • Introducing new processes to HL7: Austin, at TSC Tracker # 1681
      Status: Project Services is drafting Adoption Process document
    • Project Approval Request for EHR - Electronic Health Record System Functional Model Release 2.0, at TSC Tracker # 1806
      Status: The approval by the Steering Division of this project was contingent upon EHR FM R1.1 completing normative ballot reconciliation. Pat Van Dyke is still working on this.
    • Request for TSC to develop guidelines on what should be Informative vs. DSTU vs. Normative: Austin, at TSC Tracker # 1815 - addressed on TSC agenda Q1
    • Publication Requests for DSTU and Informative documents at TSC Tracker # 1900, 1905, 1908, 1910, 1911, 1912, and 1915
      Lynn will coordinate with Don Lloyd to close these trackers when the material becomes available on the website
  2. (May) Elect TSC Representative to Nominations Committee (Per GOM Section 10.06.01)
  3. (May) Review, update, and develop new entries for TSC Three-Year Plan
  4. (May) Review TSC Communications Plan - how are we doing against it?
    • Work Group Health metrics
      • review "Healthiest Work Groups"
      • review suggestions
        1. Add metrics to WGH for % of projects having next milestone date in the past (Tracker # 1649)
          Status as of 2010Oct: Evaluate Project Health before tying this to Work Group Health
        2. Add participation in publishing calls to Work Group Health (Tracker # 1659)
        3. Measure ballot progress in terms of overall years and in number of cycles to successful ballot (Tracker # 1660)
        4. Metric to identify whether the WG follows their own DMPs re: posting minutes (Tracker # 1683)
        5. measure coordination between WG co-chairs (Tracker # 1731)
        6. WG has a DMP based on review of the updated template, for 2011May (Tracker # 1732) - in effect this cycle.
        7. Create a Project Report Card (Tracker # 1819)
  5. (Sept) Review and re-confirm ArB membership (even numbered years)
  6. PIC slide presentation for Monday's co-chair meeting (quick review & vetting)


Q4 - TSC Project Review : 3:30 pm to 5pm

  1. TSC-sponsored projects - how to make them more effective, what should be the reporting mechanisms -
  2. Healthiest Workgroups
    • DESD: Healthiest Work Group – RCRIM [1]
    • FTSD: Healthiest Work Group – InM [2]
    • SSD SD: Healthiest Work Group – O&O [3]
    • and T3SD, with some last minute entries creating a three-way tie for Healthiest among ES, PSC, and Publishing: [4]

Sunday

- ArB

  • SAIF Book ballot update
  • ArB "what's next"

Tuesday lunch

  1. WGM Planning - agenda setting next two WGMs -
  2. Administrative Document review Schedule:
    • (January) Review TSC Mission and Charter, Decision Making Practices
      (January) Review TSC Decision Making Practices
      (May) Review TSC Three-Year Plan
      (May) Review TSC Communications Plan
      (September) Review TSC SWOT

Supporting Documents

Minutes/Conclusions Reached:

Q1 - Roadmap and HL7 Strategic Issues: 9 am to 10:30 am

Austin called the meeting to order at 9:04 am.

  1. Roll Call and Introduction of visitors (including declaration of interests) Jane Curry of ArB who is interested in perspectives for the Governance. and Grahame Grieve who is interested in everything, are in attendance. Quorum achieved with two SDs, Bob, John, and Ron.
  2. Additions to, and acceptance of, agenda: Bob requested feedback on the Strategic initiatives.
  3. Link to Interim decision review since last WGM – Lynn will post it
  4. Strategic Initiatives discussion
    • Only two strategic initiatives for 2012: Attain industry recognition as lead developer and harmonizer of global tech and functional health informatics standards, and develop standards that are easier to implement and more responsive to customer needs.
    • These are collapsed down to two from six strategic initiatives. They may be too collapsed.
    • Feedback was ‘how do you really know if you’ve achieved these?’. They suggested SMART criteria, and the objective measures were identified in 2010. They may not reflect what the TSC feels is the highest priority.
    • Austin notes the criteria development was a struggle. Tactical measures for accomplishments in one year were difficult and counter to purpose of strategic initiatives. Ed notes operational metrics are defined differently versus progress against the initiatives to indicate if we’re moving in the right direction.
    • 4.1.1 and 4.1.2 plus their descriptions need to be clear enough to identify if improvements made in that area.
    • Ed thinks an effective indicator for 4.1.1 is process to identify key standards. Ron asks how do we measure industry recognition. How are we gaining knowledge of industry’s expectations to provide value in our role.
    • Charlie notes an incorrect underlying assumption is that everyone wants industrial strength computable semantic interoperability (CSI) all the time. Need to think about deployment context and what kind of interoperability people are looking for. Linear value proposition; easy things should be easy. Don’t need to build full-deployment, universal context standards all the time.
    • Grahame adds the two contexts in interoperability in HL7; drive-by interoperability between two vendors, with fixed tech stack to adapt to local business requirements. The other thing is for national programs with universal technology stack. You can’t solve both problems with one solution.
    • The value is not just the instance of communication but the quality of data from sources being used notes Jane. The heterogenicity of standards in the org is not recognized in the world. Jane notes we need to know who are our customers and how they sort themselves into separate communities.
    • Smaller or specific scale requests are bottom-up, and national programs assert themselves at the top of the organization, notes Austin. SI objective to streamline process of top-down approach for national initiatives without choking off the little mushrooms sprouting up here and there.
    • Ron asks how do we know we are valued and by whom. Bottom up to set a a place to set requirements to be expressed in the stack and work your way through a problem. Ron says our product has to be consumable in a way such that you do not have to attend an HL7 meeting in order to use it. If we write our standards with that in mind we’ll be more successful. Austin notes that those are our vendor members’ customers. Calvin notes that HL7 operates like an iceberg, where 20% is visible to the community but used by 80%; the developers are a small group.
    • Jane notes a catch-22 where vendors tell us their customers are not asking for a certain set of functions, and the customers or users tell us that well they’re not offering that functionality. Grahame notes that it depends who you talk to, that some are wanting SNOMED and others say if you go to SNOMED we’ll go somewhere else. Patrick concurs.
    • Bob notes that the Measures, as sub-bullets under 4.1.1 are too granular and the strategic initiatives should stop at that level. We need to capture something that represents Charlie’s linear value proposition. The bullet at 4.1.1 is the measure itself and anything at more detail is tactical. Ron adds that it’s risky to articulate criteria here at the strategic level. Criteria should look at the way we frame the projects to tell us how a certain project, how we’re tracking against the SI criteria in regards to a certain project.
    • Ed takes exception to eliminating measures. You need a compass to know if you’re headed in the right direction. Patrick notes that other places where we separate strategic and tactical documents. Take the measures out of this document but don’t discard them, but have an implementation guide to the strategic initiatives. Just capture them elsewhere. John notes that Board members get involved in the tactical level details when they need to work at the strategic level. Board then is invited to get tangled in the weeds. Ron says the strategy should be manifested in the tactics. Criteria belong to the Board and the tactics or measures at the TSC level.
    • Jane asks should we maintain examples of the measures in the criteria document? TSC can report progress against the strategies using such examples. Austin asks what about a track for developing strategic standards. Bob notes that Charlie McCay always talked about the idea of a dashboard. The 4.1.1 could be a row on a dashboard. The criteria are the priorities for the organization. The progress could be reviewed once a month on a dashboard style format. The dashboard allows us to ask how we’re doing on each line. Austin notes that it might be more of a trimester basis as activity month to month might not show much. We should tie this to the project metrics that we’ll be looking at later.
    • So Bob asks how do we operationalize and monitor the Strategic Initiatives in the TSC. Austin thinks that the SAIF Architecture Program (SAIF AP) should have some oversight on that. Ron says SAIF needs to be regarded as an element of an organizational program. Other things will emerge. Calvin notes that the SAIF is like our RIM, referential framework we use. Charlie says SAIF helps you qualify what level of specificity you’re seeking in the value proposition. Calvin says TSC needs to establish the measures, the dashboard, and the reporting on those.
    • Bob notes that once we operationalize the document, you will see the organization “care” about the SI. Calvin says the TSC should communicate that we’ll take on the dashboard definition but other groups have to own certain measures, like 4.2.14 with the business and revenue model. Jane suggests the TSC review which things the TSC can manage and what are the areas out of our scope.
    • Take out the tactical portions and TSC develops a plan for the measures we own and identify those that are out of scope to allow the Board to coordinate.
    • TSC can do: 4.1.1, 2 and 3 (with International Council), 4.1.4 WGM effectiveness we can report though we have influence we don’t completely control.
    • 4.2 .1 is TSC, 4.2.2 we can measure it though we can’t control it. 4.2.3; 4.2.4 Board should work with Marketing and the International Affiliates to measure – out of scope. 4.2.5 belongs to us, 4.2.6 we can report, 4.2.7 Education Plan is ours, .8, .9, .10 are all on cross-artifact consistency to identify measurements for cross-artifact consistency for 2011 and .9 the plan for 2012, and .10 for 2013 in three-year plan. 4.2.11 Austin feels is a Board activity. 4.2.12 Gregg says the TSC has key stakeholder groups –but others may have other stakeholder groups that they must develop their own action plans. TSC will have a role they can contribute to the measurements. 4.2.13 – mapping or gap analysis would be TSC among others including ArB, CTO etc. 4.2.14 is board level but they may punt certain tasks to the TSC. Austin points out that the mapping of EHR functions to our products would actually be supporting to the HL7 product strategy. The product strategy should be a numbered item such as 4.2.16. The TSC will need to operationalize it. Jane points out that the Customer Relationship Management strategy included within 4.2.14 also needs to be closely related. 4.2.15 belongs to the Board.
    • The TSC will begin work on the process in constructing a dashboard to report these measures.
    • Ed notes that if you take out the descriptions and bullet the items you can get it down to a 2-page document – Austin suggests we call it the executive summary, suitable for the hallway conversation on where the direction of HL7 is headed.
    • HL7 and IHTSDO - Closer Cooperation (30 minutes, Bob Dolin) John Gutai and Jane Millar are not available yet.
    • HL7 Quality Plan
      • HL7 Product Quality Plan at Project Insight ID# 647
      • Austin notes that quality has a lot doing with processes used to develop standards; by tightening down those processes we’ll improve the quality of what is produced. A lot of that has to do with the rollout of SAIF in the organization. Much of that, including cross-model inconsistency has to do with governance. Woody notes that you run the risk of stagnating the organization. We need to have some balance. Austin notes there are elements of Technical quality already in the publishing process. RIM harmonization, clinical statement harmonization, common product model harmonization already model that behavior but they have been optional. Charlie notes that governance can be better received by communicating what it is that will be governed and why such areas are being governed. The governance model with the definitions exercise helps overcome even paranoia over governance processes. Jane says if you get the criteria sufficiently concrete then people can do a self-assessment without intervention.
      • Austin summarizes that the quality plan will be part of the SAIF AP; Woody suggests a chapter in the IG. Want to make sure the TSC agrees that this approach makes sense. Ed asks what from here will be in the governance document? The IG will have a governance section, notes Austin. The quality plan becomes writing that chapter, taking into effects the other elements that take it into account, with elements that cross boundaries.

Austin recessed the group at 10:30 am

Q2 – (Q1 agenda continued) 11 am to 12:30 pm

Austin called the meeting to order at 10:46 am

  1. Product Strategy - The missing strategic initiative
    • granularity in level of balloting, topic-level ballots or product briefs versus domain level (Product Strategy)
      • Earlier Work Groups were allowed to ballot pieces in order to manage workload but you have areas that are unrelated like CCOW and Arden Woody notes. RCRIM tried to take ICSR to ISO without RIM and Datatypes, which they added. John notes that in V3 there are inconsistencies between underlying foundations. The current product list is more based on how we construct the standards versus a strategic product line. Since we didn’t get orders out the door first with V3 it is symptomatic of the difficulties we faced. For example CHI has a notion of what products they need; Patrick adds that for some things like service delivery location they are going ahead and building what they need. John says that the demonstrated need is so strong that they’re building it themselves. Jane notes application functionality at a business level with behavior, we tiptoe around this with interoperability capabilities outside of certain the installed applications. Woody notes that establishing an electronic contract between organizations will bring us to the area that V2 cannot cover. Grahame notes that HL7 seems to be in the meta-standards business because the industry doesn’t have consensus on what the problems are to solve. HL7 is not in the full standards business. The pieces can turn into workable standards but we should acknowledge that we’re not producing full standards. Woody notes that the standards are not implementable but the standards are made implementable within the context of a particular environment; Jane adds the profiles need to be developed but we don’t know the environment to profile to. She says we need a clear statement of shared purpose at topic and domain level. Grahame also notes we don’t have a clear idea of what we don’t do. Contracts are a platform problem and not part of HL7’s business. HL7 as a vertical integration business where OMG handles more the horizontal platform level. Austin summarizes that we don’t have the clear product strategy and no boundaries around which we develop projects. If the Board agrees that the Product Strategy is a strategic initiative the TSC has a big part of that.
  2. Request for TSC to develop guidelines on what should be Informative vs. DSTU vs. Normative, at TSC Tracker # 1815
    • John asks are DAMs part of HL7 IP and how do we qualify them as part of our products.
    • We shouldn’t have a DSTU in the same standards space as a normative standard.
    • Are we going back to ballot normative on standards that have been hanging out there as DSTU? Are we getting rid of old DSTUs? RIM negative ballot comment on deprecated elements that are still showing up.
    • Gregg notes that the DSTU out there that don’t have any implementers, since before we required DSTU implementers to sign up before development. Also, the DSTU is freely available but once normative it’s protected IP. They also have a normative CMET and they’re working on a revision so they have a DSTU but it’s a revision.
    • Grahame notes that a DAM could be normative if they define what it means to conform to the DAM. Woody agrees that ISO standards show what it means to conform to the ISO standards. With the RIM they twiddled that conformance statement around but it doesn’t say much.
    • Some IGs are balloted normative, needing ANSI renewal after 5 years. Balloted Informative, the Technical Reports don’t expire.
    • We have two types of informative documents, one that is background information and one that is a standard, those without conformance information and those having conformance criteria. Do we need a separate category within Informative for Implementation Guides?
    • Lynn notes that none of the DSTU IGs have progressed to Normative. Ed notes that is a Normative process applicable to IGs when it’s published as DSTU for feedback and revision and an Informative guide is relatively easy to change.
    • Calvin notes that the CDA IGs are conformance constraints using schematron variations; they are actually standards.
    • V2 IGs are really guidance but are incomplete to the implementation of the standard.
    • ”Implementable Profile”; Implementation Guides may include lower level protocols. Woody says we need a place for balloting Normative specifications that are implementable for a particular purpose in healthcare. Many of Calvin’s things belong there, as implementable specifications that are standards unto themselves. They may have been deferred for Normative vote due to IP restrictions says Calvin. Woody asks what do we want to call that flavor of Implementation Guide. The CDA R2 IG are detailed technical standards. Are they properly technically constrained profiles?
    • John notes on his testimony to NCVHS on attachments, that he needs some equivalent terminology on operating rules or companion guides, etc.
    • We’ve overloaded the term Implementation Guide. How do we subdivide? Calvin says the SAIF should be informing us and we define these products in the context of the SAIF architecture. CDA R2 IGs are constraint specifications as rigorous as the schema forms. Woody suggests we stop using the overloaded term and start using other terms. Derived profile constraint specification might be a workable term. Implementation guidance for x standard in y target platform says Jane as compared to CDA use case profile, constrained variant of a balloted standard. Tighter requirements documentation should be required. Austin suggests we go with what Grahame’s note that anything on Normative track has to have conformance criteria.
    • Woody notes that Implementation Guide is an appropriate term for V2. When you promote the DSTU to Normative call it constrained standard. Ed suggests implementation profile becomes a standard which requires conformance criteria. Implementation guide is only informative.
    • Calvin asks to collaborate with other Structured Documents cochairs for what title they want to use when they go beyond DSTU for an Implementation Guide. ACTION ITEMs for Calvin to check with the Cochairs. Austin and Patrick will check on the 2.x side on an implementation profile term.
    • DSTU is proposed to be a normative track; not suitable for Informative documents. Normative track constraint specifications or what ever term they come up with from Structured Documents instead of implementation guides. Charlie notes the difference at NCI on compatibility guidelines which are not enforceable from interoperability specifications which are indeed enforceable.
    • ITS and RIM should not be allowed to be considered DSTU, maybe a new term for them as an Infrastructure Standard. Add a new row.
    • IG will be split into two constructs.
    • Eliminate DDTU column.
    • Jane adds you need to be able to identify them as well as version them.
  3. Need for statement on what V3 includes (it's not just V3 Messaging) like RIM, Datatypes, 21090, CDA, are all part of V3 - Charlie Mead.
    • ArB punted this over to the TSC. Are DAMs V3? Are Implementation Guides in V3? Ron says when people ask what is in v3, what is it? Austin notes that the SAIF AP may be determining what is in the ECCF on that for V3. With marketing and Branding, the understanding is that when you talk about V3 they assume V3 messaging and their resistance comes up. If you say in NCI that you’re implementation service architectures around RIM semantics there’s no resistance. Austin notes you are coming back to product strategy. It’s branding, technical and development methodology. Grahame feels it’s urgent to get a coherent message on this. Calvin has presented the intro to V3 tutorial as a family of standards based on the RIM. Austin asks if we can harvest that out of the HL7 copyrighted tutorial? We come back to… is a DAM, V3? Gregg comments that their DAM ballot comment was asking why they were balloting it as a V3 DAM. Woody notes that his goal is a models-based representation of HL7 specifications, which V2 is not, and so DAMs should be for V3. Grahame notes that most people feel v3 is whatever comes with the V3 publication pack, not just whatever is based on the RIM. Woody notes that CDA R1 was the first V3-based standard because of the modeling. Ed feels we need to stop using the V3 term to the outside world, but Model –based standards collection. Austin is noting the development of a “SAIF-branded” product. Woody notes we have a raft of standards that say V3 that have nothing to do with Messaging.
    • Is the publishing site subtly reinforcing the misperception?
    • Austin is looking for someone to go craft this statement. Woody says we need to consider Ed’s suggestion with a more tailored marketing perspective of V3. Discuss it with colleagues this week and show the CDA intro slide on the screen during the rotating slide show – send to Lynn and Mary Ann.
  4. Suggested rules for TSC intervention and audit of aging standards projects
    • Woody would like to see a list of the items affected as listed by Steering Divisions
    • update recommendations to show how the TSC will use the reports and be able to distribute this to the work groups. Lynn. Ron notes we want to deal with the exceptions. What do you tell the Work Groups about ballots that have no negatives? Just skip the reconciliation package and submit a request to publication for DSTU or Normative. Gregg discussed the PA CMETs for Scheduling. Calvin noted that Bob created a full one page list of things that have to be done to move a standard through. Jane asks about how to track something in project insight for projects that are on hold waiting for resources, like a status On Hold – Pending Resources.

Austin recessed the group at 12:32 PM.


Actions (Include Owner, Action Item, and due date)
  • .
Next Meeting/Preliminary Agenda Items
  • .