This wiki has undergone a migration to Confluence found Here
2016-08-17 SGB Conference Call
Jump to navigation
Jump to search
back to Standards Governance Board main page
| HL7 SGB Minutes |
Date: 2016-08-17 Time: 10:00 AM Eastern | ||
| Facilitator | Paul/Calvin | Note taker(s) | Anne |
| Attendee | Name
| ||
| x | Calvin Beebe | ||
| x | Lorraine Constable | ||
| x | Russ Hamm | ||
| x | Tony Julian | ||
| x | Paul Knapp | ||
| x | Austin Kreisler | ||
| Regrets | Wayne Kubick | ||
| Mary Kay McDaniel | |||
| Ken McCaslin | |||
| x | Rik Smithies | ||
| x | Brian Pech | ||
| no quorum definition | |||
Agenda
- Agenda review
- Minutes review of 2016-08-10_SGB_Conference_Call
- Discussion Topics
- Develop guiding principles for standards development
Minutes
- Agenda review
- No additions
- Minutes review of 2016-08-10_SGB_Conference_Call
- Minutes approve via general consent
- Austin notes that PLA's plans for rolling out a CDA product family has been put on hold by direction of TSC. There is going to be a movement towards simplification of organization infrastructure in Baltimore which has put the topic on hold. Impacts what is on SGB's horizon as well.
- Discussion Topics
- Develop guiding principles for standards development
- First is that we should manage the critical risks
- Second is that projects within HL7 should not only have author interest but demonstrate value to the community. Paul: Do we ever intend to discourage people from working on developing specifications in which they are interested and which fall within the scope of HL7? Lorraine and Austin mention cases in which projects haven't had support. Calvin: If volunteers are willing to put the time and resources towards something it would be strange to say no.
- Paul: our responsibility is to foster a community, assist it in being effective, and guide its work through a series of processes that produce a consistent quality product. Austin: Product families aren't about governing all of the details of product; rather it's about the process of developing products that our members want developed. Doesn't dictate the form and shape of the products. Calvin: Are we dealing with a balance between a top down and a bottom up world? Austin: Absolutely. Calvin: A top down approach has the need to establish prioritizations and make more resources available to meet critical needs.
- Austin: There are ways of having the community more strictly establish priorities. Could have votes of the membership to determine top 10, etc.
- Paul: We have an unsubstantiated assertion that some of the projects in which we engage take valuable bandwidth. What do we save by limiting projects? Time at the WGM, time spent managing and vetting the content for ballot, etc. Paul: How much was central time and how much was interested party time? Lorraine: The other piece is the material we put in front of our community - ballot fatigue. Group agrees we have less ballot fatigue than in the past. Paul: Do we have a metric on wasted time at the WGM or is it a gut feel? Group agrees it's a gut feel. Lorraine states some of it is taking away people's focus from others' pet projects.
- Calvin: How do we know that people are committed to the projects they're listed on as part of the team? Discussion over how the same people are listed over and over and sometimes aren't even involved in the project, although sometimes the same people are listed over and over because that's the role they fill in the WG. Accuracy of documentation problem. Gaming the process by putting in the same name every time for positions that are deemed required. May be masking a bandwidth issue. Also creates barriers to project approval.
- Lorraine: If it's a high priority project, they've often been getting external funding. That's how some of the top down stuff is happening. Calvin: Even with funded resources and projects moving through, there is a benefit to the project and to HL7 and the industry to have the volunteers look it over. Paul: There should be a) a separation of concerns across committees and b) respect for scope. When we don't support scope or separation, that's when we go down slippery slopes and make mistakes.
- Paul: So we're not here to tell people what to build. Calvin: Or we don't think we are. Austin: Telling people what to build risks alienating the members. Paul: And risks quality. Austin notes the immunization profile that is disconnected from the immunization community. In many cases requirements are not driving projects. Paul: DAMs must exist notionally if not physically if you're going to have a product line.
- Lorraine: Another principle coming out of this is that we develop our standards in a manner that is open and transparent to the community.
- Calvin: It's also possible that another issue is who is the customer that you're dealing with. Customer? Standards person? We end up with different customer views that seem to develop different philosophies. Austin: There's a view that the customer is the government regulators. Calvin: Or that the customer is the implementers and their needs are the only important ones. These perspectives have truth to a certain extent but are also a risk.
- Paul: We need to look at whether we're here for the technology supported by the business, or we're here for the business for which we derive the technology.
- Develop guiding principles for standards development
- Austin and Rik out next week
- Adjourned at 11:02 AM Eastern
Meeting Outcomes
| Actions
|
| Next Meeting/Preliminary Agenda Items |
© 2016 Health Level Seven® International. All rights reserved
