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

2017-06-06

Chair: Rob M., Susan B,. Carmela C., 
Meeting started at 2:04 ET

Agenda

1. Review and confirm use cases
2. Discussed extensibility and updated text for this.
   1. Still need to decide highlighted text in document (use of MAX/MIN) and determine if some elements of extensibility can be managed by use of data type
3. NEXT MEETING
   1. Work on discussing preferred versus required and alignment with Guidance verbs see example binding use cases
   2. Consider the approach used in US-Core bindings

2017-05-23

Chair - Rob M., Susan B., Lisa Anderson, Jim Case, Rob Hausam, Susan M.
Meeting started 2:06p EDT

Agenda

1. Continue working on set of example binding use cases
   1. We reviewed the content of the document. Made a couple of clarifications.
   2. No new use case types were identified.
2. Next meeting:
   1. Work on discussing preferred versus required and alignment with extensibility.

2017-04-25

Chair - Rob M., Lisa Anderson, Richard E., Rob Snelick, Susan B.., Rob H Meeting with quorum at 2:03p ET Agenda

1. Madrid planning
   1. Thursday Q2 With Conformance
   2. Agenda
      1. Brief review of current working material but no modifications or deep discussion
      2. Working through uses cases
         1. Craft descriptions of uses of vocab in models that need binding statement
         2. Write out the pseudo-syntax for use cases based on on working material
2. Try to focus, without concern about our current "state" on describing use cases. Work from Rob S. Use Case Sheet.
   1. we clarified the meaning of the columns. RM needs to make sure this is aligned with current thinking section for Madrid.

2017-04-11

Chair - Rob M., Frank O, Susan B., Rob H
Agenda

1. work on use cases and Franks diagram
   1. We reviewed the updated diagrams from Frank's ppt slide 27 and 28.
   2. Spent considerable time discussing how the "usable" value set, which is determined based on the value set expansion + the R/P/E might align with binding both a MIN and MAX value set. And if needed we might support one more binding of "Excluded" so that where desired (V2) codes can be explicitly not used.
   3. Also looked at FHIR Expansion Profile and $Expand and it seems that the expansion profile is describing what we consider a binding aspect.
   4. Meeting went 20 min over time.

Agenda for next meeting

1. Try to focus, without concern about our current "state" on describing use cases. Work from Frank's Use Case Sheet.

2017-04-04

Chair - Rob M., Frank O, Ted, Susan B., Rob S.
Agenda

1. Short period on review Frank's diagram
   1. Agreement that Binding work is limited to determining the set of concepts to be found in an expansion. "Concepts" in some limited situations may in fact be "expressions" that are treated as a code.
   2. Once we accomplish this we can also link this up with the VSE work.
2. Continue Franks Use case modeling
3. Next week regular meeting - work on use cases and Franks diagram

2017-03-28

Chair: Rob M., Attending: Susan B., Frank O., Ted K., Rob S.
Agenda

1. Frank and Rob S to present material based on V2 approach
   1. Frank reviewed his slides
   2. Rob started to cover his slides. He will not be on next call but encourages us to review his content

Next Agenda - to occur on extra meeting April 4 12noon EDT.

1. Short period on review Frank's diagram
2. Continue Franks Use case modeling

2017-03-14

Ted K. chair, Susan Barber, 

regrets from Rob M. who is unable to make the call today, also got regrets from Rob Snelick, who cannot make the call and has not had the time to put the material together that he was to present on today's call.

Could not reach quorum today. We wanted to:
Agenda:
From the last call, we have:

1. Rob S will present material describing their V2-based approach
   1. Rob was unable to be on the call today, so this will have to be deferred to the call in two weeks on March 28
2. Discuss usefulness of adding CEA-MAX
3. How to support definitively specifying a value set but also allow a sender to send a code not in the expansion set other than using OPEN, which allows more flexibility then this use case wants.
4. call adjourned at 2:21PM EDT due to inability to attain quorum.
5. Next call scheduled for 2PM EDT March 28, 2017.

2017-02-28

Rob M. chair, Rob Hausam, Rob Snelick, Frank O, Susan B., Ted K., Carmela C.

Agenda

1. Finalize binding strength section
   1. Agree that Binding Strength is a 4th characteristic in a binding statement.
   2. RS remains concerned that the path to implementability may not allow all the options for each characteristics.
   3. Discussion if we can combine Guidance & Binding Strength.
      1. Required v Not Required. Something like below perhaps?
         1. Required
            1. is only Fixed - implement all
            2. Is there an artifact that fits between this binding statement and the final expansion set - an expansion profile - that can restrict the set of codes that the binding statement defines. A CLOSED
         2. Preferred
            1. Preferred-Closed
            2. Preferred-Extend
            3. Preferred-Open (= Example?)
2. Frank O and Rob - Lets make examples and begin to work on this. Will begin to circulate a document with examples and first principles.
   1. Rob will review his prior document next meeting.
3. Not discussed - discuss usefulness of adding CEA-MAX

Next Agenda

1. Rob S will present material describing their V2-based approach

2017-02-14

Rob M. chair, Richard Esmond, Rob Snelick, Frank O, Susan B., Ted K.

Agenda

1. finalize binding strength section
   1. Discussion on separating this into two sections:
      1. Extensibility as already noted
      2. Binding Strength indicating if the value set is to be used or can be changed to another value set
         1. Required
         2. Preferred
         3. Example
   2. Need to look at the guidance section and pull out the aspects of this that should be put into value set definition and separate that from binding guidance. Or it may be that the "value set part" is actually more similar to the FHIR expansion profile.
2. discuss usefulness of adding CEA-MAX
   1. Defining a MAX could be broad like an entire code system, or could be a specific set of additional codes, or could be an expression. - it would be a value set def
3. Plan for work on examples
   1. list of examples we want to cover

Agenda for next meeting

1. Frank/Rob review their slides to discuss v2 meta model
2. further discussion of separating out "strength" from extensibility
3. consider how FHIR expansion profile might help - is that a 4th binding attribute we use?

2017-01-31

Rob M. chair, Rob Snelick, Jeff Danford (Allscripts), Susan Barber, Ted Klein, Stacy Marovich (CDC)

First post-WGM meeting.
Discussion at WGM focused on changes to "Binding Strength" section so that CEA conformed to current practice wherein conformance is not checked on content of the value set therein allowing addition of new concepts that are presumed to be accurate and no formal checking is expected to be done.
Agenda

1. Review WGM changes
   1. Note that we need to update the affect of use of an FHIR expansion profile on the deterministic expansion set - the effect SHOULD only be a filtering
   2. Think about adding a new section to describe conformance testability of entire scenarios and not just binding strength

Next meeting agenda

1. finalize binding strength section
2. discuss usefulness of adding CEA-MAX

2017-01-03

Rob M. chair, Ted K., Rob Snelick, Richard E.

Agenda

1. Socialize this work with other areas in HL7
   1. RE working with CIMI and CDS/CQI (CQL)
2. Jan 2017 - agenda
3. worked on top level text for use in slides

Jan 2017

1. Tues Q2 - socialize with SD
2. Thurs Q2 - CGIT working period
   1. Brief overview
   2. Null integration
   3. Max and intersection with other guidance verbs
   4. An example
   5. How is this to be published? - Policy document?
3. Thurs Q3 - joint CIMI socialize also

Not addressed

1. Ted to continue the grammatical and explanatory text updates (without any notional changes)
2. Review MAX binding additions
3. Begin to grapple with the prioritized sequence of bindings notion
4. Examine the diagram
5. Being to evaluate real examples and document them!

2016-12-06

Rob M. chair, Ted K., Susan Barber

Agenda

1. Review MAX binding addition seen at end of Guidance section #2
   1. Instead we looked in depth at the Null binding section and made a whole raft of updates and improvements
2. Begin diagram review that Rob S to send out for examples.
   1. We ran out of time before we could examine the diagram

Next Agenda

1. Next call on Tuesday, December 20 at noon US ET
2. Ted to continue the grammatical and explanatory text updates (without any notional changes)
3. Review MAX binding additions
4. Begin to grapple with the prioritized sequence of bindings notion
5. Examine the diagram
6. Being to evaluate real examples and document them!
7. Plan our priorities and activities for San Antonio

2016-11-22

Rob M. chair, Ken Lord, Rob S.

Agenda

1. Review NULL decision - RM to put this into the first section of working material
   1. Spent the entire meeting on this with some revisions.
2. End of meeting agreement that Rob M will also add a third binding type MAX that can be to an entire code system
3. Review diagrams that Rob S to send out for examples.
   1. No time for this - next meeting

Next Agenda

1. Review MAX binding addition seen at end of Guidance section #2
2. Begin diagram review that Rob S to send out for examples.

2016-11-08

Rob M. - chair, Rob S., Susan B., Frank O., Chris Herzog

Agenda

1. More on Restrict
   1. Discussed this with Rob S.
   2. Rob S. will review the work done for the V2 book and look at this in comparison with this binding semantics work - TBD in next week
2. Discussion on how Null are included in a value set:
   1. Proposal applies only to coded "nulls" and not numeric null situations (infinity, real v integer.)
   2. Maintain a Null Code System for use in "null value sets"
   3. Any coded element that will allow the use of nulls would bind a specific value set of Allowed NULLS that identifies the expected null values for that element
      1. This would would be a separate binding from the "expected values" value set
      2. Implementation of this can be unique to the program. For example it may be implemented so that both the expected values and the allowed nulls are all sent in the value slot, or the nulls might be sent in a separate data type.
      3. This means that every member of the value set is uniquely identified by the combination of the code + code system because those implementations that send everything in the value slot will need the code system to disambiguate among potentially non-unique codes.
   4. Discussion on the allowed "strength" of the specified null value set
      1. Decision was that should allow either NEA or CEA because it is acceptable to specify a null set with strength CEA that would allow a user to choose a null from the null code system that better matches the information and send that as an exception value that happens to be a null.

Next meeting agenda

1. Review NULL decision - RM to put this into the first section of working material
2. Review diagrams that Rob S to send out for examples.

2016-10-11

Rob M. - chair, Richard E., Ted K., Rob S., Christopher Herzog (WK Health), Susan B.

Agenda

1. Review Balto discuss
2. Discussion of proposal for LOINC to use binding semantics to represent a link of a LOINC code to the set of allowed "answers" (The LOINC answer set.)
   1. Would this mean LOINC would be crafting a binding statement? TK is concerned that if we call this "binding" we are extending the scope. It could be better if the binding semantic/syntax can be used in these other ways but call it something else. He proposes that a binding statement could be essentially a tupple with the initial object not always a data element, but can also be a vocabulary entity (such as a specific LOINC code), or can even be a collection of information types.
   2. Ted and Richard will work to describe this generalization of "the left side" of the binding.
3. More on Restrict
   1. Discussed this with Rob S.
   2. Next meeting need to close this addition out.
4. Next Meeting Continue discussion on how Null are included in a value set

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