2012-10-09 V3 Datatypes Task Force

Scope and mandate of this group: Need a recommendation for the V3 Modeling to the TSC.

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#

Co-chairs: Woody, Charlie
Today's Chair: Woody

Attendees:

• Charlie Mead - present
• Hugh Glover - will be late
• Paul Knapp - present
• Austin Kreisler - regrets
• Lloyd McKenzie -
• Ron Parker - present
• John Quinn - present
• Pat van Dyke - present
• Mead Walker - present

Scribe: Lynn Laakso

past meeting notes:

• 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:

• Charlie to write his narrative of Oracle's versioning strategy for reference.
• Woody asks Hugh to write up the choices as he sees them. See "Motion" below.

Product Line principles:

• CDA Principles - R1-R2 ; R2-R3 (Austin)
• FHIR Principles - evolving but more rigid than V3 (Lloyd) - see attachment
• V2 Compatibility - obtain from Chapter 2 (Mead) - see attachment
• V3 Principles - located in package note to readers on ballot site in section 5.2

Agenda

Draft Motion (Hugh):

• HL7 has not and will not guarantee wire format backward compatibility of V3 payloads as the standard evolves. However HL7 recognises that in some circumstances breaking wire format backward compatibility will cause significant difficulty to users and that this in turn will reflect badly on HL7 and have a substantial negative impact on the adoption of V3. In such circumstances, and where a resolution can be found, HL7 will publish multiple versions of affected schemas so that both new versions and old wire format backward compatible versions are available to the user community that has been affected.

• Discussion points:
  • The reason for trying to provide a backward compatible version is HL7 self-interest – we lose credibility if we don’t. We are not committing to satisfy all backward compatibility requirements everywhere.
  • We are only committing to provide a solution where one can be found.
  • We are not committing to providing the solution to everyone – but only to the group that has the issue.

Minutes

Convene at 1:10 PM

• Roll call
• Acknowledged minutes of 2012-10-02_V3_Datatypes_Task_Force
• Charlie's narrative of versioning strategy reviewed. The provider is a software provider.
  • Perspectives for both customer/consumer and provider are important to note.
  • Ron says we need strategy as requested to create an official policy, but not just frame this but do something specific in the Datatypes scenario, what sunsetting might mean for this specific problem.
  • Woody notes we have all three areas considered except perhaps for CDA but may not have described them fully (versioning, component migration, and sunsetting/component retirement from official support). Looking at V3 messaging terms, articulate the approach for support during migration.
  • What are the responsibilities for solving the problems during migration, asks Ron. Limit duration of parallel support. Can we tag in to other updates to FDA's client code to say "as long as you're updating, make this migration as well".
  • Woody notes we must define the scope of the overlap.
  • John recalls in the LRI errata issue as a cochair making the statement that the errata will be in the next published version, but that implicitly guarantees they will be in the next version as written and such a guarantee may be impossible with the reconciliation and consensus process in balloting.
  • Woody notes we have several paths for change: MnM has technical corrections, "Updates", and errata. Paul adds that typically errata are breaking changes, otherwise you wouldn't bother.

Mead joins

• Review Product Line principles:
  • V2 Compatibility - obtain from Chapter 2 (Mead) - see attachment
    • Review deprecating messages 2.1.3 section. It doesn't really address a sunsetting policy. The deprecated component is not removed from the standard. It doesn't break wire format since it's still defined in the same location but you're supposed to ignore it.
    • Charlie notes that with Oracle it had to do with test beds and what they will support. Cross-product line testing is at issue.
    • Paul notes if a standard lives for 5 years we should be prepared to support it for 5 years.
  • V3 Principles - located in package note to readers on ballot site in section 5.2
    • If we have a MDA and serializations faithfully rendered in the models, then as the models change the wire changes notes Paul. We could choose to drop the rule of faithful rendering... Mead suggests a faithful rendering with an isomorphic model.
    • Obsolescent message structure section reviewed. Woody adds they've never declared a message obsolescent but have deprecated attributes in the RIM.
    • If you made one obsolescent and offer an alternative you have to offer a transform. Charlie notes that those are data migration strategies, and while Oracle gave clients tools to migrate their data - they felt it was their responsibility to identify how the transformation should be done. They ensured the mechanics but not the labor.
    • Essentially we declared DT R1 obsolescent after R2 ballot and made efforts toward publication of R2 in the normative edition. Alternate message structures provided, e.g. in NE2012. We did not undertake transformations, but it may be possible to do so. Collection as an object itself is not semantically represented in the prior version so that would not be transformable backwards. Woody suggests we re-frame the problem in the terms used by the V3 deprecation guidance.
    • Woody further categorizes RIM changes, Data Types changes, and "inadvertent changes" from the design process. Some who implemented from the ballot find there are:
      • serialization pattern changes,
      • renaming when new elements added, or
      • changes in the "schema-generation tools".
    • Paul asks how you distinguish between the "time/edition" of a "message" to identify externally when a message structure was published. Woody notes that a 'community' should implement from a SINGLE Normative Edition and that needs to be better communicated. Normative editions have elements that are named the same but may be different.
• FHIR Principles - evolving but more rigid than V3 (Lloyd) - see attachment
  • Extensions, or sticking things at the end will look less modeled down the road.
• CDA Principles - R1-R2 ; R2-R3 (Austin)