Back to main page General meeting Connection Info

Remember USA is now on DAYLIGHT SAVINGS TIME EDT is UTC -4
Meetings occur every other week - Tuesdays @ 2pm EDT for 60 min. - alternating with VBE call
Telephone uses standard HL7 Vocab number: 1 (770) 657-9270,,,598745# - NOT THE SHARED SCREEN NUMBER FOR MIKOGO OR OTHERS
Meeting will be one of the following web share environments - see agenda for which one will be used[edit]

Mikogo session
https://go.mikogo.com/?sp=&sid=368206475
If the above link does not work, you can follow these steps instead to join a session:

Go to http://go.mikogo.com
Enter the Session ID: 368-206-475
Enter your name
Click "Join Session"

Join.Me session https://join.me/tedsnewsessions The above link works with any browser. Once there:

Click on "Knock To Enter"

Agenda topics held over:

Discussion with Templates?
1. bring Templates in once we are a bit farther along
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
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-10-17

Chair: Ted Klein
Attendees: 
Audio call-in: HL7 Conference Line; +1 770-657-9270. Passcode: 598745
Today's Screen Share:    https://join.me/tedsnewsessions.    Click on 'Knock to Enter'

Call commenced at 2:?? PM EDT when quorum reached
Minutes

Announcements
1. Rob McClure is on holiday, Ted will run this call and the next one in two weeks.
Discussion

The last call on October 3 we had a discussion of alleging concept domains/element definitions/model meaning bindings; can these be merged? Do we have a good understanding of them?

Call adjourned at 3:?? PM EDT. Next call will be in two weeks at the same time, October 31.

2017-10-03

Chair: Rob McClure 
Attendees: Ted Klein, Rob Snelick, Carmela Couderc, Susan Barber, Rob Hausam
Audio call-in: HL7 Conference Line; +1 770-657-9270.  Passcode: 598745
Today's Screen Share:     Mikogo session:  https://go.mikogo.com/?sp=&sid=368206475

Call commenced at 2:05 PM EDT when quorum reached
Minutes

Announcements
1. Rob M will be gone for the next three weeks. Ted will run all three calls - two VSE calls and the next VBS call. So Ted's web share
Discuss thinking on continued use of concept domains. This occurred during vocab/FHIR call and was influenced by FHIR approach - never to use and lack of use by CDA. So tooling will not support the creation of new concept domains based on Wed Q2 at last WGM with MnM.
1. Does this need to be revisit or accept and determine implications.
2. We have multiple ways of expressing the meaning of a coded model element. Concept domain, model element definition, model meaning binding. This has led to confusion. At times there are other conflated additional pieces of information that are included in the text associated with an instance of one of these. Can we not lose that other useful information if we try to have these become one thing. All of these are ways of describing an Indirect Binding. An element definition may have additional information that would not easily fit into an "indirect binding." Example of where the element definition has more is Observation.context with the second part of the clause providing more than what would be in a "concept domain." See the meta-definition for an element definition in FHIR here.
Next call - continue discussion on how to align items above and determine how and if "concept domains/element definitions/model meaning bindings can be merged.

2017-09-19

Chair: Rob McClure 
Attendees: Ted Klein, Lisa Anderson, Jay Lyle, Carmela Couderc, Susan Barber
Audio call-in: HL7 Conference Line; +1 770-657-9270.  Passcode: 598745
Today's Screen Share:     Mikogo session:  https://go.mikogo.com/?sp=&sid=368206475

Call commenced at 2:05 PM EDT when quorum reached
Minutes

Jay Lyle - Presentation of CIMI Semantic Design, Assumptions, and Issues that will be discussed at SNOMED, Int meeting in Oct.
1. No issues regarding binding in near term (although need for expressions in a value set may arise) and we remain interested in results of the discussion
Continue discussion from VBS at WGM based on RCM diagram for 10 min.

2017-08-29

Chair: Rob McClure 
Attendees: Ted Klein, Lisa Anderson, Jim Case, Rob Snelick, Frank Oemig, Carmela Couderc, Susan Matney, Susan Barber, Alise Widmer

Audio call-in: HL7 Conference Line; +1 770-657-9270. Passcode: 598745

Today's Screen Share:     Mikogo session:  https://go.mikogo.com/?sp=&sid=368206475

Call commenced at 2:05 PM EDT when quorum reached
Minutes

Used call to discuss what part of the project can be finished at SD WG meeting. It is clear that there is still lack of agreement on what we need to do and what "binding" is. Hope to resolve this at the WGM by walking through Current Working Material along with Frank's diagram

did not do this:

Continue on the thought directions from last week's Value Set Expansion call
1. Review the changes to the descriptions of Binding on the wiki page in the first section, clarifying the SHALL and MAY statements.
2. Review the definitions of implementable and unimplementable terminology bindings, and spent the entire call putting definitions up on the wiki page for this tow items.
3. Review the tweaks to the VSE diagram to make explicit the fact that sometimes a VSE is persisted and published, and profiled downstream to specific VSE instances of ruse in implementations.
4. Action from last call: Carmela will take a stab at drafting a definition for the phrase "currently available".
5. Action from last call: talk to the FHIR guys and see if our surmise that the FHIR Expansion Profile includes both binding and profiling
  1. Do we want to have some discussions with FHIR on this on the vocab calls? Or allocate a topic and time in San Diego?
  2. We did not get to any of this research into FHIR; Rob Hausam volunteers to follow up on some of this for the next call.
  3. Other?
6. Continue working through which objects are independently identified and curated
Next call we will continue with going through our assertions and documentation on the Wiki page, and prepare for the discussions in San Diego.
Call adjourned at 3:01PM EDT.
1. This is the last call this cycle before the San Diego WGM. The new call schedule will be setup during the Thursday afternoon planning session at the WGM. Please let the chairs know if you have particular preferences for the schedule.

2017-08-15

Chair: Ted Klein, Carmela Couderc, Rob Hausam, Susan Barber, Susan Matney

Audio call-in: HL7 Conference Line; +1 770-657-9270. Passcode: 598745

Today's Screen Share:    https://join.me/tedsnewsessions.    Click on 'Knock to Enter'
Call commenced at 2:06 PM EDT when quorum reached

Minutes

Continue on the thought directions from last week's Value Set Expansion call
1. Review the changes to the descriptions of Binding on the wiki page in the first section, clarifying the SHALL and MAY statements.
  1. We got hung up on the missing definitions of implementable and unimplementable terminology bindings, and spent the entire call putting definitions up on the wiki page for this tow items.
2. Review the tweaks to the VSE diagram to make explicit the fact that sometimes a VSE is persisted and published, and profiled downstream to specific VSE instances of ruse in implementations.
  1. We did not get to look at the diagram.
3. Action from last call: Carmela will take a stab at drafting a definition for the phrase "currently available".
  1. Not yet done.
4. Action from last call: talk to the FHIR guys and see if our surmise that the FHIR Expansion Profile includes both binding and profiling
  1. We noted that it would cleaner if we could separate Binding (controlling the set of concepts) and Profiling (controlling the metadata for each concept, and which subset is used for a particular implementation instance)
  2. Do we want to have some discussions with FHIR on this on the vocab calls? Or allocate a topic and time in San Diego?
  3. We did not get to any of this research into FHIR; Rob Hausam volunteers to follow up on some of this for the next call.
  4. Other?
5. Continue working through which objects are independently identified and curated
Next call we will continue with going through our assertions and documentation on the Wiki page, and prepare for the discussions in San Diego.
Call adjourned at 3:01PM EDT.
1. Next Call August 29, call will be chaired by ???? TBD Note this will be the last call before the WGM. Note we are likely to continue the same discussions on next week's Value Set Expansion call.

2017-08-01

Chair: Ted Klein, Susan Barber, Carmela Couderc, Rob Hausam
Call commenced at 2:06 PM EDT when quorum reached

Minutes

Continue on the thought directions from last week's Value Set Expansion call
1. Review the update to the diagram for VSE generation and how binding fits in
2. Perhaps we need to make an explicit list of what can be left underspecified in a legal VSD that must be addressed in binding and profiling
  1. We made some very small tweaks to the descriptions of Binding on the wiki page in the first section, clarifying the SHALL and MAY statements.
  2. We made a few tweaks to the VSE diagram to make explicit the fact that sometimes a VSE is persisted and published, and profiled downstream to specific VSE instances of ruse in implementations.
  3. We agreed that the phrase "currently available" is ambiguous and may lead to confusion. Carmela will take a stab at drafting a definition.
3. Since this project (Binding) and the discussions for the Value Set Expansion project are so closely related at this point, we will still plan to continue this discussion next Tuesday on the Value Set Expansion call.
Next call we will continue working through which objects are independently identified and curated
We should talk to the FHIR guys and see if our surmise that the FHIR Expansion Profile includes both binding and profiling
1. We noted that it would cleaner if we could separate Binding (controlling the set of concepts) and Profiling (controlling the metadata for each concept, and which subset is used for a particular implementation instance)
2. Do we want to have some discussions with FHIR on this on the vocab calls? Or allocate a topic and time in San Diego?
Call adjourned at 3:01PM EDT.
1. Next Call August 15, call will be charged by Ted

2017-07-17

Chair: Ted K, Rob H., Susan M., Frank O., Angela P. (NIOSH Cincinnati), Susan B.

Minutes

Frank to spend entire hour on his ppt linked below. Note that most of the call on June 20 was spent on the slides.
1. Discussion of Frank O ppt on binding. - This took entire hour.
2. We had a wonderful discussion drilling down on where binding vs. profiling and value set expanding needs to occur. It appears we are getting to a better understanding of what we are grappling with and how to untangle the pieces.
3. Since this project (Binding) and the discussions for the Value Set Expansion project are so closely related at this point, we will continue this discussion next Tuesday on the Value Set Expansion call.
Call adjourned at 3:01PM EDT.
1. Next Call August 1

2017-06-20

Chair: Rob M, Ted K, Susan M., Rob S., Frank O., Carmela C., Susan B

Minutes

Discussion of Frank O ppt on binding. - This took entire hour. Group remains concerned we have not clarified independent binding attributes.
1. Some discussion of preferred versus required and alignment with Guidance verbs see example binding use cases
2. Not sure what this was ->Consider the approach used in US-Core bindings

Next Call NOT on JULY 4, instead will be July 18 - Agenda

Frank to spend entire hour on his ppt linked above.

2017-06-06

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

Agenda

Review and confirm use cases
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
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

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

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

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

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

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.
Continue Franks Use case modeling
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

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.

Short period on review Frank's diagram
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:

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
Discuss usefulness of adding CEA-MAX
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.
call adjourned at 2:21PM EDT due to inability to attain quorum.
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

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?)
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.
Not discussed - discuss usefulness of adding CEA-MAX

Next Agenda

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

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.
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
Plan for work on examples
1. list of examples we want to cover

Agenda for next meeting

Frank/Rob review their slides to discuss v2 meta model
further discussion of separating out "strength" from extensibility
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

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

finalize binding strength section
discuss usefulness of adding CEA-MAX

2017-01-03

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

Agenda

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

Jan 2017

Tues Q2 - socialize with SD
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?
Thurs Q3 - joint CIMI socialize also

Not addressed

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

2016-12-06

Rob M. chair, Ted K., Susan Barber

Agenda

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

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

2016-11-22

Rob M. chair, Ken Lord, Rob S.

Agenda

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

Next Agenda

Review MAX binding addition seen at end of Guidance section #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

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

Review NULL decision - RM to put this into the first section of working material
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

Review Balto discuss
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.
More on Restrict
1. Discussed this with Rob S.
2. Next meeting need to close this addition out.
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

Baltimore time confirmed - Thursday Q2
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

Baltimore time - Thursday Q2
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:

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

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:

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

Did not get to this: Work on MIN - MAX and binding code systems (bottom of working section)
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

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

2016-07-19

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

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

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

The value set definition SHALL be made IMMUTABLE
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

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.

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

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)

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.

We will call the association of a concept domain with a model element A Domain Binding.
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.

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

2016-03-29

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

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.

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

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.
Began discussion on Example above.

Next meeting continue with example.

2016-02-16

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

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

Discussion on Templates
1. No one from Templates joined the call. Ted will send an invite for the next call.
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'
Should we remove all items that are not conformance focussed, or just mark those that are required (or not) for conformance?
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)
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

Discussion on Orlando Agenda
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.

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

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

Vocab VBS Minutes

Contents

Agenda topics held over:

Recent Minutes

2017-10-17

2017-10-03

2017-09-19

2017-08-29

2017-08-15

2017-08-01

2017-07-17

2017-06-20

2017-06-06

2017-05-23

2017-04-25

2017-04-11

2017-04-04

2017-03-28

2017-03-14

2017-02-28

2017-02-14

2017-01-31

2017-01-03

2016-12-06

2016-11-22

2016-11-08

2016-10-11

2016-09-15

2016-08-30

2016-08-16

2016-08-02

2016-07-19

2016-07-05

Policy

2016-06-21

2016-05-24

2016-05-12 May WG

2016-04-26

2016-03-29

2016-03-15

2016-03-01

2016-02-16

2016-01-19

2016-01-05

2015-12-22

2015-12-08 discussion

Old Minutes

Navigation menu

Search