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

Vocab VBS Minutes

From HL7Wiki
Revision as of 19:52, 15 March 2016 by Robert mcclure (talk | contribs)
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-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 discussion: 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