2010-03-29 TSC Call Minutes
Jump to navigation
Jump to search
TSC Minutes 2010-03-29
HL7 TSC Meeting Minutes Location: call 770-657-9270 using code 124466# |
Date: 2010-03-29 Time: 11:00 am - 12:00 pm EDT) | ||
Facilitator | Charlie McCay | Note taker(s) | Lynn Laakso |
Attendee | Name | Affiliation | Email Address |
regrets | Calvin Beebe | HL7 SSD SD | cbeebe@mayo.edu |
x | Woody Beeler | HL7 FTSD | woody@beelers.com |
x | Bob Dolin | HL7 Board Chair | BobDolin@gmail.com |
x | Austin Kreisler | HL7 DESD | austin.j.kreisler@saic.com |
x | Lynn Laakso (scribe, non-voting) | HL7 HQ | lynn@hl7.org |
x | Ken McCaslin | HL7 TSS SD | Kenneth.H.McCaslin@QuestDiagnostics.com |
x | Charlie McCay (chair) | HL7 TSC Chair | charlie@ramseysystems.co.uk |
regrets | Charlie Mead | HL7 ArB Chair | meadch@mail.nih.gov |
regrets | Ravi Natarajan | HL7 Affiliate | Ravi.Natarajan@nhs.net |
x | Ron Parker | HL7 ArB Alternate | rparker@infoway-inforoute.ca |
x | John Quinn | HL7 CTO | jquinn@hl7.org |
x | Gregg Seppala | HL7 SSD SD Alternate | gregg.seppala@va.gov |
x | Helen Stevens | HL7 TSS SD Alternate | helen.stevens@shaw.ca |
x | Ed Tripp | HL7 DESD Alternate | Edward.tripp@estripp.com |
x | D. Mead Walker | HL7 FTSD Alternate | dmead@comcast.net |
. | |||
Quorum Requirements (Co-chair +5 with 2 SD Reps) Met: yes |
Agenda Topics
- Introduction of visitors (including declaration of interests)
- Accept Agenda –
- Approve Minutes from 2010-03-22_TSC_Call_Minutes
- Review action items –
- CEO Report –
- CTO Report - and Fridsma's Presentation
- ArB Report – worked on schedule for Rio; no further report.
- Affiliates Report –
- Domain Experts –
- Foundation & Technology –
- Motion: to approve scope statement for Security WG's Security and Privacy Ontology Project at TSC Tracker # 1478
- Structure & Semantic Design –
- Technical & Support Services -
- WGM Planning
- Organizational Relations Committee update (semiweekly)
- Discussion Topics:
- Next week's call cancelled? Two projects outstanding - postpone to 4/12 or e-vote?
- Open Issues List
- Ballot title change request, CDS would like to change the title as it might better match the ballot contents if the name had "UML Model" removed). This is because the implementation guide contains more than just the UML model. In fact, for this cycle, the main content is content other than the UML model, which we expect will be included in the next ballot cycle.
- Request to change
- HL7 Version 3 Implementation Guide: Virtual Medical Record for Clinical Decision Support; (vMR-CDS) UML Model for GELLO, Release 1 (1st Informative Ballot),
- to
- HL7 Version 3 Implementation Guide: Virtual Medical Record for Clinical Decision Support; (vMR-CDS) for GELLO, Release 1 (1st Informative Ballot); logged at TSC Tracker # 1479
- Request to change
- V2.6 and 2.7 errata for TSC discussion TSC tracker #1523 - There are two options for moving the V2.7 ballot forward:
- Publish the flawed document with an errata
- Publish the flawed document accompanied by an errata that explains the problematic fields, how to use them correctly to maintain backwards compatibility, and noting that they will be corrected in V2.8 (and publish errata for 2.6). If Frank is agreeable to this approach and will withdraw his negative, we can publish V2.7
- All of the voters in the consensus pool should be advised of the issue. We might want to conduct a re-circulation ballot as a means of advising the ballot pool of the errata solution and letting them vote on whether that is an acceptable resolution.
- If Frank is not agreeable to this approach and won’t withdraw his negative, we will conduct a re-circulation ballot that acknowledges the problem described by the outstanding negative but offers up the errata as the solution. If this ballot passes, we can publish V2.7. If this ballot does not pass, we will have to correct the flaws and conduct another normative ballot.
- Publish the flawed document accompanied by an errata that explains the problematic fields, how to use them correctly to maintain backwards compatibility, and noting that they will be corrected in V2.8 (and publish errata for 2.6). If Frank is agreeable to this approach and will withdraw his negative, we can publish V2.7
- Correct the flaws now and conduct another normative ballot on 2.7 and publish errata for 2.6.
- Publish the flawed document with an errata
- HL7 Security Considerations - Cookbook, at TSC Tracker # 1513
- Link to wiki site http://wiki.hl7.org/index.php?title=Cookbook_for_Security_Considerations
Supporting Documents
- Fridsma's Presentation - http://gforge.hl7.org/gf/download/docmanfileversion/5543/7074/Fridsma_IS_framework_for_HITSC.ppt, or http://mycourses.med.harvard.edu/ec_res/nt/75489D65-B131-4010-B11B-68D4198E8C2A/Fridsma_IS_framework_for_HITSC.ppt
- V2.6 and 2.7 errata at http://gforge.hl7.org/gf/download/trackeritem/1523/7062/HL7_V26and27_Errata_201003FINAL.doc
Minutes/Conclusions Reached:
- Visitors:none
- Agenda: add planning call for next week. Something from Publishing, revisit discussion from changing DSTU to Informative. Left it to the Work Group's initiative to bring it to TSC if they wish to appeal. Brought it to Steering Division. Will report during FTSD. Agenda accepted.
- Minutes approved by general consent
- CEO - no report
- CTO Report - and Fridsma's Presentation
- HITSP sent out email on stuff from Halamka, with link to Fridsma's presentation, two separate meetings in D.C. at which it was presented. It talks about an Interoperability Framework for the U.S., describes state and regional HIEs, and a new NHIN Direct. Looking for clarification document to come out of ONC. Formally going with contractors to define use cases, then to one or more SDOs to build specifications. This lists the SAIF as their Interoperability Framework, which he feels is based on efforts of NCI. Ron joins the call. He feels we need info on the SAIF on the web page right away as people will be looking for it. Austin notes in looking a NIEM and sees it as a content standard for XML - asks if we are looking at converting all existing standards into XML? John thinks if we have a common reference information model it's possible. X12 probably cannot make the transition easily. Are we talking about a different wire representation. OMB supports the NIEM methodology. Will be something between RESTful and what we have now. Probably need common wrappers for V2. NIEM is also recognized unsupportive of terminology.
- ArB - per CMead, worked on schedule for Rio; no further report.
- Ron reports they are behind on publication schedule; should be remedied today. Should still have time for peer review before spring meeting; he's working on intro and will have that ready today. More significant piece of work than anticipated. Other sections to John and Karen also very soon. Suitability for public consumption to be evaluated. As the intro was initially developed they were still working out what the SAIF was. Taking the history, implications for HL7 internally and with SDO relationships as appendices. Helen asks how the intro related to the elevator pitch. Executive summary is closer to an elevator pitch now; introduction and elevator pitch have important distinctions of what SAIF is and is not. TSC action item to review elevator pitch should be to review intro.
- Action Item: Ron to pull the elevator pitch out for TSC review.
- Security Ontology review has also taken some time on ArB discussions of late.
- Affiliates: no report
- DESD: two project votes underway.
- FTSD
- Motion: to approve scope statement for Security WG's Security and Privacy Ontology Project at TSC Tracker # 1478
- This is not the Services Ontology project; this is for security and privacy
- Vote:unanimously approved.
- Woody alerts the group to the requested DSTU for Security DAM, which the TSC on prior review re-classified as informative. The Security WG were dissatisfied with the decision, its use by OASIS and other groups to create specifications in security area, they want some normative status within HL7. The Steering Division felt that it needed better documentation on their request, so with the white paper this may be revisited. John is discussing with Glickman on OASIS matters and he's glad to be aware. They had previously balloted as DSTU, perhaps before the TSC identified informative as the appropriate level for DAMs. If DAMs are represented in ways that the domain considers useful, it would be difficult to standardize that representation. How do we tell them what a normative-track DAM has to look like? We don't do so for BRIDG, for example. Gregg asks how Security will know the status of the discussion.
- Motion: TSC position; Woody moves the TSC is prepared to accept this as DSTU pending submission of request and documentation from Security WG how the model will be the basis for conformance in other groups like OASIS. Gregg seconds. discussion: Helen asks how do they show it - should they include it in the ballot material as well? Just explanation to the TSC not requiring it in their ballot material. Looking for 5-10 lines, says McCay. Helen suggests they include it in the ballot material.
- Vote: motion approved unanimously
- SSD SD - Gregg notes the SD meets later this week.
- T3SD - nothing this week
- WGM Planning - no issues raised
- Organizational Relations Committee update (semiweekly)
- Helen notes their conference call last week discussed the Mohawk contract/agreement. three aspects to relationship:
- as academic institution should apply as with all academic institution - we are looking at academic membership privileges for all such members.
- second, IP, training materials and educational materials - may need some sort of IP agreement to facilitate exchange.
- Third: Mohawk's test environment, tooling and technology activities with prototyping standards based development. Don't know what that type of relationship would be defined as, what the expectations might be. Looking for guidance from tooling committee and other FTSD areas as what the relationship and expectations be.
- Bob notes that the concept of academic research network would address a mutually beneficial relationship, or win-win agreement. Bob notes Chuck compared it to a DARPA arrangement with multiple nodes. Multiple test environments, or living lab situations would be another benefit. Need to find the best home for this effort to flesh out the details.
- Test environment in Mohawk relationship unique among other academic relationships Helen notes.
- Taking this forward, Bob looking for its home among the Working Group. Charlie suggests we discuss further next time.
- Helen notes their conference call last week discussed the Mohawk contract/agreement. three aspects to relationship:
- Discussion
- Ballot title change request, CDS would like to change the title as it might better match the ballot contents if the name had "UML Model" removed). This is because the implementation guide contains more than just the UML model. In fact, for this cycle, the main content is content other than the UML model, which we expect will be included in the next ballot cycle.
- Request to change
- HL7 Version 3 Implementation Guide: Virtual Medical Record for Clinical Decision Support; (vMR-CDS) UML Model for GELLO, Release 1 (1st Informative Ballot),
- to
- HL7 Version 3 Implementation Guide: Virtual Medical Record for Clinical Decision Support; (vMR-CDS) for GELLO, Release 1 (1st Informative Ballot); logged at TSC Tracker # 1479
- Motion: to accept name change
- Vote: unanimously approved.
- Request to change
- V2.6 and 2.7 errata for TSC discussion TSC tracker #1523 - There are two options for moving the V2.7 ballot forward:
- Publish the flawed document with an errata
- Publish the flawed document accompanied by an errata that explains the problematic fields, how to use them correctly to maintain backwards compatibility, and noting that they will be corrected in V2.8 (and publish errata for 2.6). If Frank is agreeable to this approach and will withdraw his negative, we can publish V2.7
- All of the voters in the consensus pool should be advised of the issue. We might want to conduct a re-circulation ballot as a means of advising the ballot pool of the errata solution and letting them vote on whether that is an acceptable resolution.
- If Frank is not agreeable to this approach and won’t withdraw his negative, we will conduct a re-circulation ballot that acknowledges the problem described by the outstanding negative but offers up the errata as the solution. If this ballot passes, we can publish V2.7. If this ballot does not pass, we will have to correct the flaws and conduct another normative ballot.
- Publish the flawed document accompanied by an errata that explains the problematic fields, how to use them correctly to maintain backwards compatibility, and noting that they will be corrected in V2.8 (and publish errata for 2.6). If Frank is agreeable to this approach and will withdraw his negative, we can publish V2.7
- Correct the flaws now and conduct another normative ballot on 2.7 and publish errata for 2.6.
- V2 XTN datatype in 2.6 priority order component, ch 3 and 6 previously indicated priority by sequence. PA thought 2.7 could create new fields. Gregg reviewed over the weekend; question back to Karen Van seems to impose a tighter restriction than before. Can you only send a first-priority telecom number, rather than an other-than-first priority number. John suggests he send the comments back to Karen - Gregg has already done so. With edits to the errata, this is not ready to bring to the TSC yet. Errata does not pull back the new fields from PA. Type of correction is at issue, being too restricted. Further comments please send to the list, so John can see them.
- Publish the flawed document with an errata
- HL7 Security Considerations - Cookbook, at TSC Tracker # 1513
- Link to wiki site http://wiki.hl7.org/index.php?title=Cookbook_for_Security_Considerations
- Material presented at Monday night meeting in Phoenix. How to address; send to cochairs? Do we recommend it be embedded in the HDF (Woody observes the HDF is not being managed any more, lives in limbo). Do we indicate we recommend people use it, offer it as guidance as part of our quality plan, or send the link and note the Working Group can use it or not as they like. Helen notes she heard question of this type in Phoenix. How does it apply to a V3 messages? Suggest they find a committee willing to pilot this? Woody thinks the Security WG need to do an assessment in an existing message. Prototype or example for a specific domain and then we can assess the impact.
- Woody recommends the TSC feedback is to see a prototypical analysis and assessment of an existing V3 message and see how it comes to bear; should be a concrete example of what this would mean to a typical committee when they produce such a message. Then the TSC could assess it represents an undue burden on the WG to produce such message.an Ed asks where this fits into the SAIF?
- Adjourned 12:04 pm EDT.
Actions (Include Owner, Action Item, and due date)
| |||
Next Meeting/Preliminary Agenda Items
|