Vocab VBS Minutes

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