2017-05-07 TSC WGM Agenda

TSC Sunday meeting for Madrid WGM

back to TSC Minutes and Agendas

TSC WGM Agenda/Minutes

HL7 TSC Meeting Minutes Location:		Date: 2017-05-07 Time: 5:15 pm
Facilitator: Ken McCaslin		Note taker(s): Anne Wizauer
Attendee	Name	Affiliation
x	Calvin Beebe	HL7 SSD SD Co-Chair
?	Woody Beeler	TSC Member Emeritus
?	Giorgio Cangioli	HL7 Affiliate Representative
?	Lorraine Constable	HL7 ARB Co-Chair
?	Jean Duteau	HL7 Affiliate Representative
Regrets	Freida Hall	Adhoc Member - GOM Expert
Regrets	Russ Hamm	HL7 FTSD Co-chair
?	Stan Huff	HL7 Immediate Past Board Chair (member ex officio w/ vote)
?	Chuck Jaffe	HL7 CEO (member ex officio w/o vote)
x	Tony Julian	HL7 ARB Co-Chair
x	Paul Knapp	HL7 FTSD Co-Chair
x	Austin Kreisler	SSD-SD Co-chair
x	Wayne Kubick	HL7 CTO (TSC member ex officio w/vote)
x	Ken McCaslin (Chair)
x	Anne Wizauer(scribe, non-voting)	HL7 HQ
?	Melva Peters	HL7 DESD Co-Chair
x	John Roberts	HL7 DESD Co-chair
Regrets	Andy Stechishin	HL7 T3SD Co-Chair
?	Sandra Stuart	HL7 T3SD Co-Chair
?	Pat Van Dyke	HL7 Board Chair (member ex officio w/ vote)
x	Lloyd McKenzie
x	Josh Mandel
Quorum Requirements (Co-chair +5 with 2 SD Reps) Met: (yes/No)

Sunday evening Agenda Topics

1. ArB
2. BAM
3. FHIR - R3 lessons learned
   • Invite delegates from FMG, SGB, FGB
   • FHIR publication naming
4. Product family addition to support CIMI
5. SGB recommendations regarding ballot level change requests - Calvin

Minutes/Conclusions Reached:

• Quorum reached at 6:25 PM
• Reviewed Ken’s co-chair dinner slides in light of yesterday’s conversation.
• FHIR - R3 lessons learned
  • Invite delegates from FMG, SGB, FGB
  • FHIR publication naming
    • Lloyd: 2 naming issues: One is that current naming policy says that the release number has to restart. With FHIR we expect to do a publication every 18 months-ish. Our next publication, Release 4, will hopefully include some content that is normative, some that is STU, and a little that is draft. STU says this is ready for production; draft is work in progress to give a sense of what is going on (comment only). In subsequent releases, the volume of content that is normative will increase over time. Austin points out similarity between FHIR and V3. Lloyd: Difference is that we don’t expect to produce a normative edition. Intention is that there will be a publication every 18 months containing a mix of content and we would like such publications to be known as R4, R5, R6, etc. Given that the product will contain a mixture of content, it’s not clear when it would make sense to reset the count on the number, and from a marketing/implementer perspective, resetting the counter would be a bad idea. Paul: The name can’t say it’s a normative edition or have a ballot level because it will have mixed content. FHIR Release such and such is convenient; however, we use the term release with a number in other ways which could also be confusing. Austin: We also need to talk about packaging FHIR for ballot purposes. Lloyd: Second portion of the naming issue is conditioned publishing of the FHIR core specification; we also publish implementation guides. US Core has a certain number of resources in it and some may eventually be normative. So it doesn’t just affect the core spec, it also affects IGs. Calvin: The ballot part is where we may run into ANSI issues. If you take content through ballot with a singular name that could be a problem. Lloyd: We may run two parallel ballots on one artifact – one on normative content and a second parallel ballot on STU content. Paul: That’s fine, and there could also be a for comment for the other bits. The key thing is in the normative ballot – if there are five resources, and four go through and one needs changes, you can’t move forward with the four without the fifth without reballoting. If you want to be able to move those resources forward separately, they have to be individual packages. If anything in the package fails, the whole package fails. Lloyd: Logistically we have 100 resources, and the dependency hierarchy is variable. Lloyd’s leaning is to go forth with a single package. If we hit a circumstance where something doesn’t pass and we make the determination that the thing that failed is reasonable to only pull it and pass some of the others, we would go back for a second technical ballot of reduced scope to the same ballot pool. The label on what goes to ballot will be 2018-05 and what will go to ballot a second time is 2015-09, and when that’s resolved we would have FHIR Release 4. Calvin: Is the scope of the second ballot only if this subset is appropriate to go together or can they comment on other non-substantive changes? Paul: You can either scope it to the clean stuff, or if it was just one issue that you changed to fix the ten, you could scope to changes. Lloyd: When we put stuff out for ballot they can comment on anything, and we can make things unrelated. Austin: Comes down to clearly defining the scope of that second ballot. Any of those comments will hang around, though, to be resolved later. Lloyd: The initial ballot will go out, we can triage the comments on normative content, and fairly quickly identify the ones that are going to have substantive change vs. the ones that are fine. We can put out to the community the re-scoped normative up/down vote during the period of time that we’re still reconciling and applying changes on everything else. Paul: You would have to complete and include any of the changes to the subset that you’re keeping. Those items in the reduced scope have to be completed. Lloyd asks if there has to be a ballot snapshot for the revised balloted items; group responds yes, due to ANSI requirements. Austin states that ANSI essential requirements are quite simple; it’s our interpretation of them that is more complicated. Lloyd states the second snapshot could be the one used for Connectathon. Paul notes the time differences between doing an out of cycle ballot vs. in cycle. Ken states there could be value to doing out of cycle.
    • ACTION: Ken will follow up with Lynn to find out about out of cycle timelines
  • Naming issue, continued: Wayne, Grahame, and Ken have been grappling with the issue. The second challenge is that we have FHIR core, we have IGs based on FHIR core, and all of them have version dependency. What we have right now is US core, release 1 (based on FHIR release 3); next time around we could have US Lab Release 1 based on US Core release 2 based on FHIR release 4; our experience has been that HL7 insiders have looked at that and been confused. If insiders are confused, the implementer community will definitely be confused. The question is: Is there a labeling scheme for the core spec and for IGs that will make evident the dependencies and will be relatively intuitive to the implementer community? Ken is wondering if it really all has to be in the title. Lloyd; It’s really what are the names we are going to use and can it be referred to in a succinct, intuitive, and precise way. Paul: I would keep the name of the IG to the name of the IG – just it. Then would require a standardized badge inside the IG listing the versions and dependencies. Lloyd: It may be using a different term for the core spec vs. the IGs. Austin: No substitute for keeping track of metadata. Need to get this figured out by R4.
    • ACTION: Calvin will help with the FHIR naming issue. Lloyd will provide some examples.
• Pushed to future meeting:
  • ArB
  • BAM
  • Product family addition to support CIMI
  • SGB recommendations regarding ballot level change requests - Calvin

Actions (Include Owner, Action Item, and due date) .

Next Meeting/Preliminary Agenda Items .