NIST position on V2+ email – to get us to the goals of phase 1 for next V2+ ballot

We (NIST) have been discussing the v2+ project and specifically its progress, direction, chance of success, and the effective use of our resources. We believe the project has made little progress in the past year and is, essentially, at a standstill. On-going discussions have drifted from the original intention to include scope expansion (which we thought had already been decided upon). We can’t seem to break away from it. The project is at a crossroads and must go firmly in one direction or the other. Below is a summary of the direction we think the project should focus on, and what we will participate in. We don’t want to overly influence a consensus group, but, at the same time, we can’t justify using our resources for a project we think is going in a direction that is in opposition to our program (i.e., the project is not what we signed up for) and in opposition to what we believe is a sound technical approach.  We’re sure you can appreciate the situation, as all organizations need to periodically assess projects and allocate resources.

Below is a summary list of our position, followed by limited explanatory reasoning. On an upcoming call, we would like this list (a focused project direction) to be considered as a formal motion and, hence, a project roadmap. We want to make clear that the intention of the motion is to propose a path forward such that the group can focus on a distinct set of tasks so the project can be completed.

Regards,

Rob and Michael (and NIST management)

Summary List:

1. Focus on a new, modern FHIR-like presentation view using the existing 2.9.1 content.
2. The content view and interpretation must be compatible with the existing v2.x framework and the v2 conformance methodology standard.
3. Reorganize the presentation view to support a logical and natural navigation of the content.
4. Retain a monolithic standard, i.e., do not split v2+ into a core framework and base standard profile.
5. Keep the v2+ base standard vocabulary model simple.
6. Adopt and discuss one-and-only-one tool stack.
7. A computable tooling approach.
8. Identify impacts of proposing and adopting changes to the fundamental v2 concepts.
9. Keep discussions focused on these over-arching principles only.
10. Future (add-on) Tooling

List with Explanatory Reasoning (Note: The intent of the expanded explanations is to provide further insight such that those who are not seeing the whole picture might better understand why a particular stance is being sought. We can provide clarification, but do not intend to argue each point—this has been discussed ad nauseum in our meetings):

1. Modern content view of version 9.1.: The content and attributes to define the content remain the same within that current base standard framework. That is, concepts of general code sets (tables) and conformance constructs are fundamentally not changed. This is represented in what we are now calling the v2 classic view. Minor adjustments to the column names, such as replacing repetition with cardinality, fit within this framework. No other presentation view SHALL BE considered (one-and-only-one view SHALL BE developed). The v2+ project will accept the decisions made during comment resolution for the January 2021 ballot for comment as the baseline for continued progress.
2. The content view and interpretation must be compatible with the existing v2.x framework and the v2 conformance methodology standard. This enables a seamless bridge for v2+ conformance profiles from the v2+ base standard. Furthermore, adopting this policy maintains a consistent representation of the conformance constructs and profiling mechanisms across the entire v2 spectrum (i.e., all versions of v2.x and v2+). Adopting multiple formats and conformance mechanisms has substantial impact on existing processes, artifacts (e.g., multiple profile schemas and XML profile instances would now exist), tooling infrastructure, implementations, etc.
3. The existing content of HL7 v2.9.1 shall be reorganized into levels (as proposed, levels 1-4) and for the healthcare/business elements into domains (level 4). Levels 1-4 are the HL7 v2+ base standard proper. Levels 5 (Conformance), 6 (ITS), and 7 (Implementation Guidance) provide a broader v2* perspective and resources. For example, conformance methodology is applicable to all v2.x and v2+; likewise for data type libraries, additional vocabulary resources (e.g., UTG, references to PHINVADS, VSAC), implementation guide registry, and a proposed level 8 tooling resources).
4. Do not add a profile layer to v2+. Adding a base standard profile layer in our opinion has no practical value and instead will cause significant confusion. The base standard is just a framework; what matters in the end are the interface requirements documented by a profile. The profile is the mechanism that defines the real interoperable specification. Yes, it would be nice if the base standard was error free, but for real implementations being compliant is of little or no consequence (e.g., in the case of a base-level optionality code for patient name). Implementers already have a work-around today, and if a profile were to document the element as not supported, exactly what harm is being done if the parties involved agree and it meets their use case—which is what we want in the end, to correctly convey requirements. Do we really need a base standard profile layer and all that would come with it to indicate this? Maybe just simply add a note stating in such circumstances that an error was made, and specifiers have a choice for these particular elements to override in a profile? Presumably folks will want to document a profile to meet their requirements and not try to circumvent a rule.
5. The v2+ base standard vocabulary SHALL remain simple. In principle, the concept domain, and any referenced code sets (tables) should remain the same. The new display format can add value and convenience. Additionally, the classifications provided by NIST are to be adopted (this proposal was presented over a year ago and accepted—if not then, we are proposing it now). See the slide deck for an in-depth discussion of the proposal. The initial description and code listing in the base standard are used as the starting point for progressing from concept domain and code systems defined in the base standard to code systems and, finally, value sets in conformance profiles. The existing conformance methodology provides a rubric and “cookbook”-style process for creating and documenting the vocabulary resources.
6. Tooling: One-and-only-one tooling stack should exist. A decision needs to be made on whether it is tooling developed by NIST (lead by Michael) or Frank. Once decided, only that tooling stack will be discussed on the calls and in any correspondence. It is the responsibility of the v2+ tooling group to ensure that requirements set forth are being correctly implemented in the tooling. The party that is selected to do the tooling shall be responsible for managing the development, maintenance, and operation of the software described above.  No other tooling efforts SHALL BE discussed or shown.
7. Tool Approach: The primary source of truth for future versions of v2 shall be in a format that is, by design, computable.  This format shall be serializable.  The serialization format shall be documented such that an appropriately educated person shall be able to reconstruct v2+ in its entirety from the serialized format.
   1. This stands in contrast to maintenance of the primary source of truth as a collection of MS Word documents.

Develop software tools that consume the computable source of truth and produce a static HTML rendering that:

1. Expresses the computable standard with extreme fidelity
2. Stylistically resembles other HL7 standards products, specifically FHIR (while not adopting any of the FHIR meaning or interpretations—this remains v2).

The HTML rendering will provide stakeholders with a single(!) representation of Data Type, Segment, and Message Structure definitions.

1. Consideration of the impact of deviating too far from the v2.x existing set of core principles and workings: HL7 v2.x has an extremely large imprint in today’s healthcare data exchange installation base and, therefore, an extremely large implementation base. What is the appetite of implementors to adopt yet another standard (albeit the proposed one-off, with new usage indicators, vocabulary, and core profile, is not a total redo). Although, they may seem somewhat innocuous, they are not to implementations. From a NIST perspective, we have evaluated the consequences it would have on just one of our tools (IGAMT, a profiling tool). Although not overly difficult to incorporate, the resource cost and maintenance cost are high (especially when we see no return). Additionally, we would never intend to implement it and, thus, would break from a documented standard. Our belief is that other (most) implementers would make a similar decision.
2. At the beginning of each call, this set of guidance principles should be briefly mentioned and referred to if discussion drifts from the task list to complete the project in a timely manner. Members can call attention to the principles to refocus discussion.
3. Future (Add on) Tooling: The development of software tools that enable v2+ authors to edit the standard through a web interface is beyond the scope outlined above but is still within the larger scope of the overall v2+ effort.  If these tools prove necessary for the production of a first v2+ publication, then we will expedite their development.  Otherwise, we will delay working on them until after the approval of a first v2+ publication.

• Project was started to improve V2, not just to create a web representation of the content (which has been available for years in Frank’s webpages)
• We do need to align V2+ representation with what FHIR developers are used to seeing.
• For phase 1 not including MUST support and the base profile and who is developing the conformance tooling
• Frank was providing input and NIST was going to build the tooling
  • What is missing for tooling to get phase 1 done?
  • Need to have the restructured wording from chapters to new organization
  • And some of the vocabulary representations for V2
• We agree we will have phase 2, but for these calls we will focus on the topics to get phase 1 done
• What about re-evaluating the usage of all elements to create the NEW BASE profile – this analysis has not been done yet, but might be benefical
  • In the end the conformance profile for the implementation defines the requirements – but you could be non-compliant with the base standard, but still be conformant to the profile, which is what makes interoperability work – the conformance profile represents the business requirements and as long as you are in conformance with that is what matters
  • A looser base standard would still be helpful for vendors to be in compliance with the base more easily – not sure if this was for phase 1 or not
  • If you are pre-adopting elements, then you no longer have versions, so we really should get rid of the version numbers and just declare publication dates
  • Use the exact specification for this use case, include computable requirements for functional testing
  • We had discussions around V2+ being the a la cart menu to chose building block
• This email was intended to re-iterate what was decided upon and verify we are all on the same timeframe
• When phase 1 ends, when we have completed ballot and published the first version of V2+

Motion to adopt the email content as goals for phase 1 of V2+ and proceed and to keep the conversation in the V2+ topic to this scope on Friday calls – Rob, Amit further discussion: would the tooling be available to anyone if NIST does not continue past phase 1? – all NIST tooling is in public domain, source code, no restrictions on modifications – using MIT license, do we include phase 2 in the motion? – leave out for now – abstain: 0, against: 0, in favor: 6

Motion to have NIST develop the tooling for phase 1: Michael, Amit, no further discussion abstain: 0, against: 0, in favor: 6

Motion to plan for additional phase for V2+ and prepare content via zulip stream or in other venues Frank, Michael, no further discussion abstain: 0, against: 0, in favor: 6

• Next week:
  • V2 tooling call: Discuss the slicing of content next week
  • Late call:
    • Diagnostic Audio IG publication Request
    • Gender Harmony Block Vote
    • Gender Harmony Jiras
• Early call in 2 weeks:
  • Pulled items from Gender Harmony Block Vote around use of OBX and repeating GSP