20121107 TSC Risk Assessment call
Jump to navigation
Jump to search
TSC Risk Assessment Task Force Agenda/Minutes
HL7 TSC Meeting Minutes Location: call 770-657-9270 using code 985371# |
Date: 2012-11-07 Time: 9:00 AM U.S. Eastern | |
Facilitator: Austin Kreisler | Note taker(s): Lynn Laakso |
Quorum n/a | |||||||
Facilitators | ArB | Members | Members | ||||
x | Austin Kreisler | resigned | Charlie Mead | regrets | Calvin Beebe | x | Pat van Dyke |
x | Jane Curry | resigned | Ron Parker | x | Ed Tripp |
Agenda
- Review the Ballot risks spreadsheet from Pat, on Chapter 13 of the GOM.
- Review the GOM sections spreadsheet
- Review Consolidated risk assessment spreadsheet
Supporting Documents
- See links
Minutes
Minutes/Conclusions Reached:
- Review the Ballot risks spreadsheet
- Pat reviews risks from Chapter 13 of the GOM. She still is planning to review sections 14 and 15.
- No comments on the ANSI technical report registration process
- Mitigation of risks related to lack of US Affiliate
- May want to capture the reason for the GOM in the first place, to separate out procedural details from the bylaws. Allows incremental change without full membership ballot. Risk also that lack of update results in actual procedures differing from those documented in bylaws. Key risk is the ANSI audit that finds we are not following our processes. Now we've created a bureaucratic framework that is slow when we need to be nimble.
- Review the GOM sections spreadsheet
- Austin reviewed which sections are not under the TSC purview and solicited volunteers for other sections
- Review Consolidated risk assessment spreadsheet
- Focus on those risks deemed critical and high likelihood. Five of the 10 in focus are resource-related.
- Communication with ANSI regarding standards under development - both communications and process related. Should be documented as two different risks. One can be Policy and Process differences between HL7 and ANSI.
- Need to understand the rationale for why we have a process in place. We're trying to recover the documentation of the rationale but need to keep in mind the big picture level as we consider requirements, notes Jane.
- Austin views the charge of this task force is to identify and surface the risks but not to begin addressing the mitigation directly.
- Risk to global adoption: inability to simplify implementation prevents global adoption (SI 2.1.3, 2.3.2). 2.x space isn't so much the risk of adoption but standardization in implementation. V2 was syntactic interoperability rather than semantic. CDA is much more successful. May not be solely a technology problem. FHIR is addressing it as a technology problem, rather than requirements. CDA uses an engineering model to break problem into smaller pieces. FHIR keeps simple things, simple; reduces problem space. Is the mitigation through technology?
Next Steps
Actions (Include Owner, Action Item, and due date)
| |||
Next Meeting/Preliminary Agenda Items |
© 2012 Health Level Seven® International. All rights reserved.