2012-09-12 V3 Datatypes Task Force

first meeting, Constellation E, 2012Sep WGM
Woody, Charlie cochairs

Attendees:

• Austin Kreisler,
• Mead Walker,
• Hugh Glover
• John Quinn,
• Ron Parker
• Paul Knapp
• Lloyd McKenzie
• Pat van Dyke

Scribe: Lynn Laakso

Definition of wire-format backwards compatibility discussed. Board motion: Within a major version or family of HL7 interoperability standards, including DSTUs, wire-backwards compatibility of successive dot versions and releases is the goal.

• More of a business and political problem than a technical problem. Woody notes it is also a technical problem, in the implications to all the implementations
• Lloyd asks for scope and mandate of this group. Need a recommendation for the V3 Modeling to the TSC.
• John notes that the Board said last night that the TSC needs to come up with a definition of releases and how that relates to backwards compatibility for all products, going forward. Not necessarily applying backwards at this time. Woody notes the policy is in the V3 Normative edition which was just published, and has been in there for all its iterations.
• Lloyd notes that MU references ISO Datatypes 21090 specifically in Quality Measures. Discussion ensued on whether that reference was deliberate or editorial. Paul feels it's deliberate and surprising that no one brought it up before now. The R1 of that standard uses Datatypes 1.1 but the earlier version was informative and the current release is DSTU.
• Woody asks if the exogenous adoption of ISO datatypes in the affiliate community; it was not discussed at the International Council. It's used by CRO certainly notes Charlie. Woody says that means we can't abandon a path to R2. What are the management problems imposed by forking, and what are the marketing problems. He further asks if the ITSs talk about the various releases. Paul says R1.1 expresses Datatypes of R1 backwards compatible to wire format plus non-breaking changes. R2 is R1.1 plus breaking changes.
• Mead suggests you can publish RMIMs using Abstract DT R2 and publish schemas using R1.1. You produce two sets of schemas but not two sets of diagrams or ballot packages.
• There are four breaking changes. R1.1 is backwards compatible, but R2B is not. What's the difference between R2 and R2B? Four Datatypes ITSs, R1, R1.1, R2B, R2, and now FHIR. There are still changes that Gunther wants that cannot be accommodated in a backwards compatible way. Lloyd asks, for what reasons do you break backwards compatibility? Are the reasons of value to one stakeholder more important than the value of the reasons of another stakeholder…
• Hugh also notes that we only have one complainer. Other major V3 stakeholders and big systems use their own generators and schemas, not straight from the ballot. Current material in the ballot is not wire format compatible with previous versions. Using the HL7 public schemas and claiming conformance to home-grown schemas was discussed. Woody adds there are elements in the ISO schemas that FDA doesn't want to appear.
• Differences between R1.1 and R2B - created solely for response to Gunther's - these are the breaking things that FDA wants that somebody else will find broken using R1.1.
  • PIVL.frequency is added in R1.1 by agreement, but no agreement required in R2B
  • COLL.collectionNullFlavor - by agreement in R1.1, no acreement required in R2B
  • COLL.Collectino Type - no present in R1.1, at all + note about COLL being abstract
  • QSC (GTS) code not in R1.1 at all, in R2B
  • ST/ED.value as attribute - not in R1.1, in R2B

• Mead notes that he does work for FDA and wants to make their camp happy.
• Woody asks the three biggest items in R2 that are not in R1.1 - these things described are in R2 not in R1.1. Hugh notes there are 40,000 records in existence written in R1. What are the things that would be wrong in R2. Wire format changes enable industry best practice tools to read the data. Hugh has done transforms on SPL for display name and in PQ that R2 could read. It's not that big a deal. It's not about reading existing files it's the system interfaces. Woody asks how the SPL images vary.
• Lloyd reports that the new semantic content in R2 is not Gunther's issue. It's the representation of that content and how some existing semantic content was changed. Other implementers don't care about our tools since they've customized their own. Major changes R1 to R2 in how collections are handled where R2 has a wrapper and R2B has characteristics about the group of items in the collection. R1 GTS was a mess . Name/address in entity name changes where R2 has "part". It is vocabulary driven rather than element driven. Paul adds foreign content in R1 was a separate namespace, where R2 allows an attribute to qualify the HL7 namespace, but this is in Structures not Datatypes.
• Data types R2 makes a number of changes that ease implementation by new implementers, but provide no benefit to existing implementers but still require change. Cost but no benefit. Implementers at FDA going to V3 were already made unhappy, and forced into another change with no benefit will make them still more unhappy. To support the newest version of SPL they have to change code anyway, to adopt data elements relevant in R2B. To run the transform on the inbound content prior to change would be only three more lines. Revamping how you handle name/address, collections, and timing is much more change.
• Analogy to those implementing MU CDA guides will be equally upset when they see CDA R3. R1 datatypes used in one part of MU and R2 in another will be surfacing among implementers soon and the ONC will have to resolve.
• What are the implications of maintaining a fork for 6 years? Do we limit the fork to specific topic spaces? If we fork, Lloyd says, we must produce the transforms to move between them. Woody asks how many zones in the ballot would be affected? Would Pharmacy be affected? Just FDA. Woody summarizes that he's hearing the direction going towards creating a fork. Some are uncomfortable with it. If that is the understanding, what do we have to support? Austin notes that HQMF wants R1.1, and there are elements of R2B that will break it.
• Woody proposes Tuesdays at 1 PM EDT starting September 25th.

Adjourned at 1:40 PM EDT