This wiki has undergone a migration to Confluence found Here
2017-12-06 SGB Conference Call
Jump to navigation
Jump to search
back to Standards Governance Board main page
| HL7 SGB Minutes |
Date: 2017-12-06 Time: 10:00 AM Eastern | ||
| Facilitator | Paul/Calvin | Note taker(s) | Anne |
| Attendee | Name
| ||
| x | Calvin Beebe | ||
| Lorraine Constable | |||
| Russ Hamm | |||
| Tony Julian | |||
| x | Paul Knapp | ||
| x | Austin Kreisler | ||
| Wayne Kubick | |||
| x | Thom Kuhn | ||
| Ken McCaslin | |||
| x | Rik Smithies | ||
| Sandy Stuart | |||
| Quorum: Chair + 4 | |||
Agenda
- Agenda review
- Approve Minutes of 2017-11-29_SGB_Conference_Call
- Action Items
- Paul to ask Vocab to approve a motion that it was the WG’s intention in R3 for the Expansion profile to be balloted as STU. If PA has not documented approval, send them the same message
- Paul to verify with Karen that the documentation on the FHIR R3 ballot STU approvals is sufficient
- Anne to add review of edited Product Life Cycle document to TSC agenda
- Approved. Need to determine where to post.
- Anne to add Mixed Ballot Precept to precepts section of wiki page
- TSC leadership to discuss RDAM project
- Discussion Topics
- Further review of definition of "Standards Under Review (SUR)" definition from the Standards Privacy Impact Assessment
- Backwards compatibility consistency and definition across families
- Precepts We Need to Develop
- Parking Lot
- Review GOM with respect to where SGB and precepts should be reflected
- Review Publishing M&C updates regarding dual roles
- How do we deal with making sure that WGs involve those whose content domain they’re touching? (CIMI and Pharmacy and Lab models)
- Review Mission and Charter
- Handling situations where two documents come out of one project
- FHIR Product Director Position Description: we should 1) review further and draft feedback, then 2) map back the description to the role of FGB
- Drafting Shared Product Management Responsibilities
- Levels of standards
- Separation of concerns
- Ownership of content
- ISM
- Ask methodology groups to define how the definition of substantive change applies to their product family; management groups must then operationalize
Minutes
- Agenda review
- Approve Minutes of 2017-11-29_SGB_Conference_Call
- MOTION to approve: Calvin/Austin
- VOTE: All in favor
- Action Items
- Paul to ask Vocab to approve a motion that it was the WG’s intention in R3 for the Expansion profile to be balloted as STU. If PA has not documented approval, send them the same message
- Carry forward
- Paul to verify with Karen that the documentation on the FHIR R3 ballot STU approvals is sufficient
- Carry forward
- Anne to add review of edited Product Life Cycle document to TSC agenda
- Approved. Need to determine where to post.
- ACTION: Anne to add review to FGB agenda with note that we'd appreciate their review to make sure we haven't missed any points; if it's fine, forward on to FMG and we'll send to other management groups.
- Approved. Need to determine where to post.
- Anne to add Mixed Ballot Precept to precepts section of wiki page
- Carry forward
- TSC leadership to discuss RDAM project
- TSC leadership discussed. Wanted project to put on hold while TSC invites them to come to an upcoming call to discuss. Project is too large, and CIC does not seem to want to be the sponsor - would be more appropriate as an interested party or cosponsor. Will introduce a whole new methodology. Governance issue is massive projects coming in and disrupting everything; also how these things should be introduced to HL7 process. Discussion over differences/similarities with FHIR and CIMI. Will monitor the situation and act when it comes back to us.
- ACTION: Schedule time in New Orleans on Friday to come up with a precept on how to bring in large projects.
- ACTION: Add work plan (short term and long term) for SGB to New Orleans agenda
- ACTION: Elect replacement chair for Austin, who will be ad hoc starting in January; will need to recruit replacement member.
- Paul to ask Vocab to approve a motion that it was the WG’s intention in R3 for the Expansion profile to be balloted as STU. If PA has not documented approval, send them the same message
- Discussion Topics
- Further review of definition of "Standards Under Review (SUR)" definition from the Standards Privacy Impact Assessment
- Thom: The question here is that we asked them to define SUR and they haven't defined it. They're proposing a change in procedure for the development of our standards; however, they don't propose what they want changed. It's a mish mash of other people's documents. Austin: They want people to be mandated to follow their process, which TSC has not been comfortable with in the past. Thom: What is their objective? What are they trying to make happen that is not happening now? Paul: They are trying to get people to figure out how privacy will or may be implemented as it's being developed, rather than developing the spec and figuring out how to bolt on privacy at the end without altering the specification. Appreciate the goal and intention but uncomfortable making it a "shall" rather than a "should" at this point. Austin: Core problem is that if you're trying to incorporate into your spec, you still need the privacy and security experts present, and mostly you don't have those in a volunteer organization. Calvin: SUR is not applicable in our methodology at this point. If they want to have a new process, there are ways to do that rather than balloting it and having it become law. Adoption is not mandatory for anything. Austin: Do we let this go forward and be published? Doesn't see a reason to block publication, but perhaps we should tell the TSC to not make it a mandate. Calvin: They're trying to apply their specification to any standard being developed by HL7. Thom: But they never talk about how this would work in terms of workflow. Who would do it? The document bring in process that is suggested but not clear. Calvin: It's not looking at our processes specifically. Trying to advocate that you can build it into standards rather than applying it to implementation. Paul: The privacy by design movement is because of the difficulty of actually doing a full and complete, efficient job of privacy after the fact because it doesn't engineer in correctly. This is something that would need to be picked up at the methodological level. Paul: Is there sufficient definition in teh document that we're comfortable letting it be published? And given the presence of this, do we wish to alter our recommendations in terms of its application to existing standards? Austin: We can make a recommendation as to whether they should be allowed to proceed. Thom: A great deal of clarification is required that should have been addressed when it balloted. For example, no standard ever contains PII. What it contains are fields that, if they were filled, might contain PII. Instances conformant with the standard may contain PII. Calvin: Perhaps we need an intro paragraph to explain more about how this is to be used. Paul: Could give them the sample that in a future release they clarify things like "this SUR contains PII." Need the definition of an HL7 SUR, not another organization's definition of an SUR.
- ACTION: Ask them to include in the document of an SUR that is independent of another SDO's process that relates to us directly. Advise that a future release of the document needs to have some front matter stating that this specification is advocating considerations for other standards and specifications under development to consider when those standards, when implemented, would potentially contain PII, therefore sentences such as "This SUR contains PII" should be written as "Instances which are conformant with this SUR may contain PII." This release should contain clarification on how it is to be interpreted.
- ACTION: Anne to invite to next call to discuss
- Thom: The question here is that we asked them to define SUR and they haven't defined it. They're proposing a change in procedure for the development of our standards; however, they don't propose what they want changed. It's a mish mash of other people's documents. Austin: They want people to be mandated to follow their process, which TSC has not been comfortable with in the past. Thom: What is their objective? What are they trying to make happen that is not happening now? Paul: They are trying to get people to figure out how privacy will or may be implemented as it's being developed, rather than developing the spec and figuring out how to bolt on privacy at the end without altering the specification. Appreciate the goal and intention but uncomfortable making it a "shall" rather than a "should" at this point. Austin: Core problem is that if you're trying to incorporate into your spec, you still need the privacy and security experts present, and mostly you don't have those in a volunteer organization. Calvin: SUR is not applicable in our methodology at this point. If they want to have a new process, there are ways to do that rather than balloting it and having it become law. Adoption is not mandatory for anything. Austin: Do we let this go forward and be published? Doesn't see a reason to block publication, but perhaps we should tell the TSC to not make it a mandate. Calvin: They're trying to apply their specification to any standard being developed by HL7. Thom: But they never talk about how this would work in terms of workflow. Who would do it? The document bring in process that is suggested but not clear. Calvin: It's not looking at our processes specifically. Trying to advocate that you can build it into standards rather than applying it to implementation. Paul: The privacy by design movement is because of the difficulty of actually doing a full and complete, efficient job of privacy after the fact because it doesn't engineer in correctly. This is something that would need to be picked up at the methodological level. Paul: Is there sufficient definition in teh document that we're comfortable letting it be published? And given the presence of this, do we wish to alter our recommendations in terms of its application to existing standards? Austin: We can make a recommendation as to whether they should be allowed to proceed. Thom: A great deal of clarification is required that should have been addressed when it balloted. For example, no standard ever contains PII. What it contains are fields that, if they were filled, might contain PII. Instances conformant with the standard may contain PII. Calvin: Perhaps we need an intro paragraph to explain more about how this is to be used. Paul: Could give them the sample that in a future release they clarify things like "this SUR contains PII." Need the definition of an HL7 SUR, not another organization's definition of an SUR.
- Backwards compatibility consistency and definition across families
- Carry forward
- Precepts We Need to Develop
- Carry forward
- Separation of concerns re: FHIR
- Carry forward
- Further review of definition of "Standards Under Review (SUR)" definition from the Standards Privacy Impact Assessment
- Parking Lot
- Review GOM with respect to where SGB and precepts should be reflected
- Review Publishing M&C updates regarding dual roles
- How do we deal with making sure that WGs involve those whose content domain they’re touching? (CIMI and Pharmacy and Lab models)
- Review Mission and Charter
- Handling situations where two documents come out of one project
- FHIR Product Director Position Description: we should 1) review further and draft feedback, then 2) map back the description to the role of FGB
- Drafting Shared Product Management Responsibilities
- Levels of standards
- Separation of concerns
- Ownership of content
- ISM
- Ask methodology groups to define how the definition of substantive change applies to their product family; management groups must then operationalize
Meeting Outcomes
| Actions
|
| Next Meeting/Preliminary Agenda Items |
© 2017 Health Level Seven® International. All rights reserved
