This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Vocab VBS Minutes

From HL7Wiki
Revision as of 18:57, 13 September 2016 by TedKlein (talk | contribs) (→‎2016-09-15)
Jump to navigation Jump to search

Back to main page

Agenda topics held over:

  1. Discussion with Templates?
    1. bring Templates in once we are a bit farther along
  2. Continue discussion from Orlando to determine if we can push into the V2 Specification the following:
    1. Binding to the combination of a profile + data element
    2. Capture the details of "the column in the V2 spreadsheet" within a value set that is the one referenced by the 'a profile + data element bound value set
  3. Future details for discussion later:
    1. How to support definitively specifying a value set but also allow a sender to send a code not in the expansion set. OPEN allows more flexibility then this use case wants.
    2. Focus on how to clarify what subsequent types of changes that are Conformant with the specified binding
      1. Expansion changes based on code system version change
      2. Changes in VS definition (a new version) that may or may not lead to a different expansion set
    3. Identify the items in the material below that should be pulled out as not "conformance-focused" and therefore not a part of the formal Binding specification, and instead are Guidance (but should still be stated.)

Recent Minutes

2016-09-15

Rob M. - chair, Ted K., Susan Barber, 
regrets:  Rob Snelick

quorum met, meeting commenced at 2:15PM EDT

Agenda

  1. Baltimore time confirmed - Thursday Q2
  2. Review the notes that Rob made from the discussions with Stan (below the minutes from the last meeting)


Next meeting times, agenda, and priorities will be set at the face-to-face in Baltimore next week Baltimore items for discussion next week:

  • Discuss the new notions of RESTRICT
  • Go over carefully the use case from Stan, i.e. must use the specified encoding for a specific set of concepts, but permit concepts that are not in the bound value set
  • Review and get agreement on our need to focus on pragmatism in our definitions, model, and advice


Meeting adjourned at 2:58PM EDT.

2016-08-30

Rob M. - chair, Ted K, Soraya Assar (ESAC), Rob H., Rob S., Susan B.
Not here: Richard E.

Agenda

  1. Baltimore time - Thursday Q2
  2. Review NULL discussion from last call
    1. By NULL we specifically mean a statement regarding Data not available
    2. By doing this we would be making explicit something that has not been specifically stated in IGs
    3. Discussion hinges on the ability to convey if a value is "Proper" (normally expected value) versus "not-proper" (data availability information). In V3 not-proper data can be sent in a different data-type attribute, but in V2 it would be identified based on the use of the NULL-Flavor code system.
    4. Proposal
      1. If nothing is declared, then all null flavor values are permitted.
      2. A subset may be defined for the entire IG
      3. For a specific model element, you may further constrain for that model element
      4. Implementers are to use as specified.
        1. If no value available is appropriate, the data element may be left unvalued.
      5. How the value is conveyed by the implementer:
        1. V3 - separate slot
        2. V2 by code system
        3. More to come.


Agenda for next meeting

  • Finish definition of how implementers are to construct instances that conform to the specified NULL binding.
  • 2016-09-02
    Rob McClure met with Stan Huff and Susan Matney to discuss the use of this binding semantics approach as a way of describing the linkage of a LOINC observable to a prescribed set of expected/required Answers (a LOINC Answer Set). Stan agreed that this would be an enhancement to LOINC (both Lab and Clinical) wherein a "Binding Statement" would be added using these semantics to the association of a LOINC observable to a LOINC Answer Set. Even better if we can also define a value set identifier for that Answer set so the binding would be a full statement. Stan had two issues that we need to discuss:
  1. Need to add text that clarifies that a binding always defines a situation where any changed "downstream but conformant" value set will have a scope that is fully aligned with the originally bound value set, even for EXTEND and OPEN bindings.
  2. He describes a use case that is in essence a combination of CLOSED + EXTEND wherein a downstream conformant value set could have 0..N of the originally defined concepts plus can add additional concepts that do not exist in the original value set. This computably could be considered similar to an OPEN binding but he wants to communicate - essentially to a human that is interpreting the binding - that this binding does not give the freedom of OPEN, but instead requires use of expansion set if possible, and very tight alignment to the particular concepts noted in the original binding. Perhaps we could call this a RESTRICT BINDING.

2016-08-16

Rob M. - chair, Ted K, Soraya Assar (ESAC), Rob Snelick, 
Not here: Richard E., Rob H., Susan B

Agenda

  1. Finish the use of NULL discussion
    1. Group agreed that a separate Use of NULLs Binding should be done.
    2. This additional binding would be applied to all coded elements unless explicitly stated to not allow nulls. Syntax for this must be defined.
    3. This binding will have a default for (all of HL7?) that would be all null concepts in the NULL code system are allowed - this value set would be the default reference if not stated.
    4. A subset of NULLS can be defined - via a value set - and applied for use on coded elements.
    5. The declaration of if nulls can be used and which null value set is to be used can be done in three places:
      1. Default for all models is all nulls allowed with value set xxx. This is what is done if nothing is specified.
      2. At the beginning of an IG to be applied for all coded elements as noted within the IG. Assume that it might be possible to specify this as some sort of identifiable type of coded element that is then applied across the entire IG. This could even be doe for an entire modeling type (like FHIR or V2).
      3. For a specific coded element. This would be a NULL-Specific binding for that single element that is in essence a second binding for that element.
      4. Because of this, unless nulls are explicitly excluded, we are saying that ALL coded elements would have a value binding and a null binding.
    6. All Null Bindings would be NEA.
    7. The Null binding set of expansion codes are valid for use in whatever model component is specified as the "bound" element. If they are bound to the value component then they are valid members of the value BUT they are not to be considered members of the non-null traditional value set expansion. Instead they are an additional value set expansion the can be sent in the value slot. These will be identified as separate from the expected value set expansion by the fact that they are drawn from the NULL Code System. This means that to easily distinguish them from an "expected value" value set expansion member, NULLS can not be in any expected value expansion set. This will help clarify that a NULL value is always describing value metadata and not actual value content. So OTH as a Null is not the same as "Other" in a value.
    8. We need to clean up how use of nulls is currently described in the working material.


Agenda next meeting:

  1. confirm above. place it into the working material. fix the null descriptions.

2016-08-02

Rob M. - chair, Ted K, Richard E.,Rob Snelick, Rob H., Susan B

Agenda

  1. Did not get to this: Work on MIN - MAX and binding code systems (bottom of working section)
  2. Ted - edge cases examples
    1. Null flavor in a NEA VS
      1. V2 restricted flavors of null (FON) are made explicit members of the expansion
        1. Null flavors are included as part of the datatype. Rob S notes that in specifying the value set using his table approach, they add the null flavors into each CLOSED value set.
      2. CDA - @Code is used to tell the data type can only use a concept from the value set and no NULL flavor
      3. CDA & V3 also allows restriction of no Datatype nulls and instead a smaller subset of nulls allows in the value field (as if in the value set.)
    2. Discuss led to these potential approaches
      1. Consider encouraging guides to have a separate NULL Flavor binding statement that is separate from the value set bindings - will this work if there are lots of element by element changes in desired behavior?
      2. Choices:
        1. Add the null flavors as regular codes to the value set definition so they end up in the expansion set
          1. Directly into the value set member list
          2. As a separate value set that is grouped with a "expected values" value set into a "grouping value set" that is then bund by the element. Issue with this is that binding semantics (CLOSED, etc.) could not be specified in the guide because the behavior of the value set binding would only apply to the grouper as a "uniform" whole.
          3. As a complex binding that defines the expected value value set plus an "OR" to the binding for the null value set to be used when the regular set can't be used.
        2. Somehow allow a guide the ability to specify the null flavors the datatype can use. This specification would function like a Null Flavor Binding to be applied to the datatype use of nulls in it's null element.
    3. Remember that CEA binding is still possible: But this was not designed to send a NUll, it was designed to allow a sender the ability to send some other code that is not a NULL type. Yet it could be a NULL. In that case it could be "OTH" in the value and the NULL "OTH" sent as the exception code.



Next meeting
Agenda

  1. Rob may not run call - Ted will run
  2. Finish the use of NULL discussion

2016-07-19

Rob M. - chair, Ted K, Rob Snelick, Rob H., Susan B.

  1. Agenda
    1. Review and complete the new top section of the current working section
      1. Group agrees that this section is correct. - reviewed in V2 context.
      2. Rob M created a diagram that will be linked to the wiki.



Next Agenda: Work on items at the bottom of the TBD section - MIN and MAX

2016-07-05

Rob M. - chair, Ted K, Rob Snelick, Susan B
Agenda

  1. Finish discussion on the below item. Ted to work more on value set binding perspective as the starting point:
    1. The following describe implementable bindings.
      1. A Value Set Binding can be described (declaration) for a model element and when this is done, all jurisdictions must remain conformant to the binding which can still allow change as noted in our binding semantics. [V3 Model Binding]
      2. A Value Set Binding can be described (declaration) for a scope that is not directly tied to a specific model element yet. [V3 Context Binding]
        1. We need to make this more clear and use existing constructs so we are not adding complexity to everyone's world view.
    2. A Domain Binding is an unimplementable binding that simply describes a scope for some future value set binding.
  2. Items we need to come back to that need to also be handled here:
    1. Canada - a sequence of bindings that are to be implemented where if one binding is not used, a defined second one is used.

Group worked on adding this into the initial part of the current working material section.

Policy

When a value set definition is all the codes in a code system and this is not LOCKED to a specific code system version, Then:

  1. The value set definition SHALL be made IMMUTABLE
  2. The name of the value set SHALL be the same as the code system (to make it easier to see the alignment of content.)

Ted moved this as a motion, Rob S. second. 3/0/0 motion carries. This will be brought to vocab main meeting and placed into a policy document.

There may be situations where creating an immutable "total code system" value set is improper such as ISO Country Codes. It is likely that this policy should be followed for any code system that has multiple concept identifiers for the same concept (eg: codes) in frequent use.

Given the need to have a value set for all of the the 2-char codes in the code system and another value set with all the 3-char codes in the code system. In this case it would be improper to make a value set of just the code system in it's entirety because there is a need for code-specific value sets.

Next Agenda: Review and complete the new top section of the current working section

2016-06-21

Rob M. - chair, Ted K, Rob H, Susan B

  1. Agenda
    1. Concept Domain - enter this into the Current Working Material section
      1. Ted is opposed to the inclusion of "Domain Binding" as a type of binding. He would like to have bindings be computable for conformance testing. A concept domain is a characteristic of the data element. He also thinks that a concept domain can accept both a model meaning binding (IHTSDO - a computable meaning of the element) and an instance value binding (a value set)

Updated section:
Concept Domain: A uniquely identified named description of the ideas intended to be used to express the semantics of a coded model element. This uniquely named description may be represented by a concept drawn from a code system, but in all cases it is not intended to specify the allowed instance values that may be exchanged or recorded in the noted model element.

  1. We will call the formal expression of a scope with a model element A Domain Binding. This is intended to convey a vocabulary declaration that is not directly implementable and is a concept domain.
  2. We will call the formal expression of the association of a value set to a model element A Value Set Binding.

The need to be able to align an expressed scope to a specific value set binding, for example when binding to a scope based on jurisdictional requirements, is called Context Binding in V3 Core Principles. When a value set binding is made directly to a model element, thus removing the ability to have jurisdictional differences, this is called Model Binding in V3 Core Principles. In V2 both what we are calling Model Binding and Context Binding can be expressed in a document external to the V2 model specification.
So this means that a a value set binding can be done directly to a model element, or to a "a scope" which can be implemented using a model element that is underspecified at the time of the value set binding declaration.
Next meeting July 5:
Agenda

  1. Finish discussion on the above item. Ted to work more on value set binding perspective as the starting point:
    1. The following describe implementable bindings.
      1. A Value Set Binding can be described (declaration) for a model element and when this is done, all jurisdictions must remain conformant to the binding which can still allow change as noted in our binding semantics. [V3 Model Binding]
      2. A Value Set Binding can be described (declaration) for a scope that is not directly tied to a specific model element yet. [V3 Context Binding]
        1. We need to make this more clear and use existing constructs so we are not adding complexity to everyone's world view.
    2. A Domain Binding is an unimplementable binding that simply describes a scope for some future value set binding.

2016-05-24

Rob M. - chair, Susan B., SueAnn Svaby (NextGen)

  1. Agenda
    1. Review material and introduce concept domain discussion

2016-05-12 May WG

Agree that there is a need to include in our description what is traditionally considered alignment to a concept domain, as a kind of "binding" where in it is distinct from instance focused traditional value set binding.

Concept Domain: A uniquely identified named description of the ideas intended to be used to express the semantics of a coded model element. This uniquely named description may be represented by a concept drawn from a code system, but in all cases it is not intended to specify the allowed instance values that may be exchanged or recorded in the noted model element.

  1. We will call the association of a concept domain with a model element A Domain Binding.
  2. We will call the association of a value set to a model element A Value Set Binding

2016-04-26

Rob M. chair, Ted K. Calvin B., Rob S.

  1. Discussion of examples
    1. Consider Discussion at May WG with SD
  2. Added a new section that would be required element of binding - description of sender/receiver behaviors.
  3. Next meeting is Thursday Q1 or Q2 in Montreal


2016-03-29

Ted K, Calvin B, Frank O, Susan B, Rob M, Rob H.

  1. Calvin has joined us to go over some of the needs and ideas from SDWG and CDA
    1. We had a robust discussion on the notions of OPEN and CLOSED, and we have adopted the notion of FIXED, but are still grappling with its meaning and relationship, in other words is FIXED (vs. non-FIXED) orthogonal to OPEN and CLOSED? If so, there are four permutations, but it is unclear what they all exactly mean. Rob M articulated a nice permuted set here, and promises to document it in the Wiki under our general principles notes.

2016-03-15

Rob M., Rob S., Ted K., Susan B., Jim C.

  1. Example work
    1. Continued to discuss and try to clarify how to define an example. Rob M. will craft a state diagram to help identify the different "types" of bindings.
    2. Others need to bring a real susceptibility model binding so we don't start from scratch
  2. Next meeting Rob M. will be in Panama so look for changes in meeting

2016-03-01

Rob M. Chairing, Ted K., Susan B., Frank O., Serafina V

  1. Discussion confirming that the content of binding information can be spread over multiple documents as occurs in:
    1. V2 (a data element from a model in a guide/standard + a profile) or
    2. US eCQM (a data element with an vs OID + vs version/code system version in release info)
    3. TK: loosely coupled binding attributes means that the linkage between binding attributes can permit multiple cardinality so that more than one value can be associated with the binding attribute that are loosely coupled.
  2. Began discussion on Example above.

Next meeting continue with example.

2016-02-16

Rob M. Chairing, Rob Snelick, Ted K., Susan B., Frank O.

  1. Discussing V2 use of Profile tables where a coded element in the original IG with binding specified is "fully bound" in a separate profile
    1. We have agreement that the full set of binding information can be in two places, the original IG and a separate document where the remaining binding information is provided. This can also describe what subsequent constraints are allowed.
      1. This is similar to the eCQM Binding Parameter Specification document, and V2 Profiles.
  2. The ability to extend the deterministic set of concepts in a value set is slightly different in V2 from V3
    1. V2 the new concept must be included in a newly created profile where the new code is available to all - so what changes is content of the value set
    2. in V3 the user can send the new code as a user-specifed addition of the value set but the deterministic concept of the value set does not change.
    3. These need to align but may support either updating the VS definition (new version) or support for an "OTHR" code that is not in the expansion.
  3. Need to create real examples to run through these elements. This needs to be our focus for the next meeting.

2016-01-19

T. Klein (chairing), Rob Snelick, Rob Hausam, Jim Case

  1. Discussion on Templates
    1. No one from Templates joined the call. Ted will send an invite for the next call.
  2. Further exploration of V2 (NIST) view of the binding definition
    1. We looked at the NIST slides in detail again and Ted went on at length with Rob Snelick on the places of overlap between the tabular view NIST has developed and what we are documenting here in this project
    2. Must put together more detailed set of Use Cases that illustrate the different flavors of 'OPEN'
  3. Should we remove all items that are not conformance focussed, or just mark those that are required (or not) for conformance?
  4. We did not get time to explore and document further the Use Case of an instance of a data element containing a coded value not in the bound value set and the conformance rules and implications wrt what must be allowed and/or prohibited (and thus what must be captured in the syntax)
  5. Call adjourned at 3PM ET; next call will be in 2 weeks on February 2

2016-01-05

T. Klein, R. McClure, R. Hausam, R. Snelick, F. Oemig, S. xxxx

  1. Discussion on Orlando Agenda
  2. Focused on item 3. Need to work through how to allow use case described in Orlando Agenda. Ted to bring another use case.

2015-12-22

T. Klein, R. McClure, H. Grain, R. Hausam.

  1. Moved "further allowed constraint" section to #3 from being #2. Cleaned up text in this section and moved content from #1 to this section. Section is not complete.
  2. How is DYNAMIC to work?
    1. Allowing changes to expansion set determined by the same value set version based on a different code system version.
    2. A restriction of the concepts in the default expansion based on the definition originally specified, using a new value set
    3. DYNAMIC in core principles value set binding is restricted to code system version used and need to determine how this should apply to changes in VS version.

2015-12-08 discussion

  1. Concept Domain:
    1. MAX value set actually is a computable statement describing concepts that represent the semantic space/concept domain allowed conceptual domain.
    2. In FHIR a Data Element Definition is exactly the same thing as a V3 "Concept Domain", both of which define the semantic space for the model element.
    3. Prose statement that describe "behavior" of subsequent users wherein changes are allowed when that subsequent user wants to implement something different than the deterministic binding.
    4. What needs to be done is to pull out items from above that describe this "behavior" stuff and make that not a part of the binding semantic.
    5. It is aligned and needs to be included, but would not be BINDING SPECIFICATION

Old Minutes

2015-07-07_Binding_Minutes
2015-07-21_Binding_Minutes