2012-10-23 V3 Datatypes Task Force
Scope and mandate of this group: Need a recommendation for the V3 Modeling to the TSC at the end of this month.
Occurs every Tuesday effective 9/25/2012 until 11/27/2012 from 1:00 PM to 2:00 PM.
TSC concall coordinates Dial 770-657-9270 and enter pass code 985371#
https://www2.gotomeeting.com/join/225603658
Co-chairs: Woody, Charlie
Today's Chair: Woody
Attendees:
- Charlie Mead -
- Hugh Glover -
- Paul Knapp - present
- Austin Kreisler - present
- Lloyd McKenzie - present
- Ron Parker - regrets
- John Quinn - regrets - in Stockholm
- Pat van Dyke - present
- Mead Walker - present
- Scribe: Lynn Laakso
past meeting notes:
- 2012-10-16_V3_Datatypes_Task_Force - The task force agrees that the solution should be an R2B "fork" to be made normative and made available for use to a "defined" community of applications for the duration of the R2B specification. Challenge now is to define the community and be assured that this is a sufficient solution for them
- 2012-10-09_V3_Datatypes_Task_Force
- 2012-10-02_V3_Datatypes_Task_Force
- 2012-09-25_V3_Datatypes_Task_Force
- 2012-09-12_V3_Datatypes_Task_Force
Action Items:
Action Items: none this week
Agenda
- Approve minutes of 2012-10-16_V3_Datatypes_Task_Force
- Show a general framework of the problem and use the framework to address the Datatypes problem (Documenting what we have in place is important and then apply the Oracle model)
Minutes
Convene 1:10PM
- Roll call
- Discussion of V3 principles - see Versioning_and_Backwards_Compatibility_in_V3
- Review approved motion: In keeping with the "V3 Principles", HL7 believes that standards must be able to evolve as new requirements and new solutions are presented. Wire-format backwards compatibility has served HL7 extremely well in the Version 2 and CDA environments and should remain a core objective for evolving HL7 standards.
- Review approved motion: In keeping with the "V3 Principles", HL7 believes that standards must be able to evolve as new requirements and new solutions are presented. Wire-format backwards compatibility has served HL7 extremely well in the Version 2 and CDA environments and should remain a core objective for evolving HL7 standards.
Nevertheless, when "breaking changes" are proposed and approved through HL7's standards-setting processes, HL7 has an obligation to provide a reasonable "migration path" for those who have implemented the prior standards. Going forward, the approach will be based upon the declarations of obsolescent and obsolete standards, as discussed in the V3 principles.
- Lloyd notes CDA not trying to be backwards compatible. We can't keep up with forking each version. Wire format compatibility should be a prominent objective or consideration in all HL7 standards.
- Woody proposed to InM to deal with two problems at once, to revitalize the four wrappers and update for deprecated items. Such updates would introduce breaking change.
- Lloyd recounts multiple sources of breaking change. If the standard is to evolve we cannot (not just 'will not') guarantee wire format backward compatibility.
- Discussion of obligation to provide migration path. Semantic backwards compatibility is certainly to be provided. Providing transforms is not an obligation we want to accept. If we maintain separate wire-format backwards compatible version then it's an unsustainable forking strategy.
- Coupled with any forking strategy HL7 must have a timeline with an expectation of progress on a migration path towards a sunset of support.
- Mead notes that FDA is willing to commit resources to support this effort. Most of the implementations are in other jurisdictions having taken control of the model to maintain backwards compatibility - we may not see any native V3 UV implementations. FDA would rather not have a sunset clause or far enough away to be the indefinite future. 5 years is much preferred to 1 year, for example.
- Woody notes the duration of the R2B would be an ANSI standard for 5 years, barring reaffirmation.
- From the wiki page, the motion for dealing with Data Types R2B: "The Task Force recommends that the Data Types R2B go forward to Normative ballot in January 2013. This specification shall be formally recognized as a "fork" of the Data Types R2 ITS, and will be made available to a "defined community of applications" for the duration of the R2B's existence…" - where the existence is defined to the ANSI period with expectation of migration.
- Community of applications includes implementers clustered around regulated products, including CDA R2 implementations.
- Lynn asks about support from the vendor for the five year span. Gunther wrote the generator and provides MIF files, notes Mead. Single-source point of control is a worry notes Woody, but support for the first five years shouldn't be too difficult. Mead thinks it will require tinkering. Lloyd says we'll stop generating those schemas, to control them. Generator will show what the changes would be. Manually tweak the schema to accomplish the same ends. Lloyd suggests that the community would have to manually manage the schema.
- Community of implementations with CDA R2 all use a Datatypes R1 schema. CDA R3 will be an issue, and will not be wire-format backwards compatible. Austin notes that its backwards compatibility is already under debate. Woody notes that HL7's challenge is whether to create two variants of CDA R3, with DT R2 and DT R2b. Lloyd notes that the policy we come up with has to work for HL7 in the event it comes up with CDA as well - process needs to work. Lloyd notes there are other factors besides datatypes that may create wire backward compatibility issues in CDA R3. Woody notes that the CDA issues can be confined to a work group. Adding an ITS can affect all WGs. At ITS last week Paul notes they moved to reconcile the R2B ballot and reballot in Janaury if needed.
- Woody would like to get this wrapped up next week if possible as the following week conflicts with Harmonization. He'll try to put a revision up and circulate it for review.
- Paul asks that we address DSTU from the original Board motion for following backwards compatibility. Austin notes that the TSC needs to begin to enforce that in project approval as a new criteria. Current GOM rule is that wire format backwards compatibility is not a consideration. DSTU is not an end state.
Next meeting 2012-10-30 V3 Datatypes Task Force
Adjourned 2:02 PM EDT