Attendance can be found Here
Co-Chair and Key Participant information can be found on the Agenda found Here
Binding semantics, resume work on this project
Definition: association between a coded element and the set of permitted values that may be carried in that element
Moved HG seconded JC that the definition approved yesterday be modified to replac elegal with permitted values
Vote: For 8, Against 0, Abstain 0.
Comment: This concept is used extensively in HL7 messaging.
At each specification or profile level the binding may become increasingly specific. e.g. at the international model level a concept domain is specified and at implementation guide level specific codes may be identified.
In HL7 vocabulary binding is the mechanism of identifying specific codes to be used to express the semantics of coded model element in information models or coded data types.
There are terms used that are associated with specific vocabulary binding use cases:
The different HL7 families have different methods of moving from a non-implementable binding to an implementable vocabulary binding.
Guidance on how the 'rules' are implemented in each product family is needed. When considering implementable and non-implementable requirements think about the current binding types that have been defined and identify if that type is implementable or not. Specifying this would be valuable to clarify the intended use.
When you need to determine the terminology elements to be used in a specific time, data element, use case context - we have not defined what has to be defined in the binding and whether that is dependent upon the use case (i.e. if for validation - is this coded item legal or not? - this is a very different use than a collection of constrained elements available to a clinical user
As an implementer I just want to know what I have to be able to support. The writer of an implementaiton guide may be looking at the binding from a persepctive of what is allowed. There seems to be a difference in what is required based upon that perspective and use case.
Based upon the use case that the IG supports - what is the binding necessary to support this use case.
Everything which is not focused on what is required for an IG is out of scope for binding terminology constraints in the IG at a point in time.
Objective is to define the metamodel for binding to assist the development of IGs (not the future requirements for vocabulary bindings). Some requirements may be use case specific and others use case independent and this must be clear. If not use case specific the binding is likely to be non-implementable. The use case is often defined to a point (e.g. national IG with known leniance to support state veriations). In an IG there are no non-use case specific requirements.
Bindings in implementation guides are always use case specific (to a specified level). For situations where overarching information about the terminologies associated with a data element needs to be defined. Advice is provided (not implementable) which can form the basis for use case specific IGs. This advice is potentially confusing and whether such advice should be given was discussed. It may be more appropriate to constrain at the relevant point downstream rather than constrain or advise too high in the activity levels.
We should not have any terminology space communications that go from the designers of the implementation model to the authors of the IGs.
A binding may be universal (where everyone agrees how a concept is represented e.g. monetary currency codes), which is implementable and established at a high level and promolgated down into individual IGs.
Where an Profile (type of IG) does not have a constraint for an implementable vocabulary specification and binding, there may be a concept binding (high level non-implementable binding).
Further actions: Define the three components of binding
- Ted Klein take the further actions list and add to the binding call agenda - to determine next steps.