Terminology binding and constraint
Modelling the full semantics of the health domain is complex. This is because it is an information intensive industry. Some health concepts clearly make up the stuff of the Information Model - things such as record architecture, times and dates, typed data and constraints. Other health concepts belong in a Reference Terminology or Concept Model - such things as diseases, symptoms, medicines ; in general these are single concepts or relationships between them. You don't want a software engineer hard wiring clinical ontology into the information model. Some clinical data could sit in either and an example is Family History. Guidance in this circumstance is available through the work of HL7's TermInfo work group discussed in a paper by Markwell, Sato and Cheetham presentation_markwell.pdf . A third model is known as the Inference Model or Guideline Model. This represents concepts or objects where their state is contingent on concepts in the other two models.
See this diagram by Alan Rector et al:
Source: Rector A, Taweel A, Rogers J, (2004) Models and Inference methods for Clinical Systems: A Principled Approach, Proceedings of MedInfo 2004
This 'model of models' is also a useful paradigm for understanding GLIF and GELLO, discussed elsewhere in the wiki. GELLO use in archetypes will be described later in the TEMPLATES section of the wiki.
So, if we accept archetypes as being information model constructs, then some sort of link needs to happen to 'bind' the local terms in the archetype or template, to a richer semantic for that concept, in the Reference Terminology / Concept Model (such as SNOMED-CT, or information space (such as LOINC). More than one binding must be accomodated. Constraints on the concept model need to be catered for . An example of a terminology constraint in plain English would be something like 'the allowable field values for this node must be this SNOMED-CT Concept or any of its children' .
Binding to terminology
Binding terminology to EN/ISO 13606 archetypes/templates is achieved by using the Edit terms button 
. The bottom pane is where the binding can occur.
An alternative approach if you are binding to SNOMED-CT is to right click on an ELEMENT node in the Tree View and use the Add Snomed Term to Node button 
Adding SNOMED-CT terminology constraints
Constrained SNOMED-CT values that are allowed for a node (like a Value Domain) can be created by using the Edit constraints button on the main menu bar 
. This example is for the video example in the box further below. It shows a populatable Edit Constraints window:
Go back to the selected ELEMENT in Tree View in the main archetype tree on the left hand side. Expand it. Click on the child ReferenceSectionData under your given ELEMENT. On the right hand side click on the word (Codes) which is next to Choices. Then click on the button on the right hand side of this 
. In the window that opens, click on the button on the right that looks like a yellow pill 
. Choose the constraint, and OK out. You have linked the constraint to the node or ELEMENT.
Example video showing GELLO linking the Information and Guideline Models:
An archetype using SNOMED-CT knowledge
In it we can see how the example archetype is structured appropriately as a view on a part of the information model
for the top two fields, but the third field is a very bitsy sort of boolean, with a narrow focus perhaps to a surgical
or gastroenterology clinic. The temptation is to build these sort of screens for any 'sub-culture' we are dealing with
in the Health domain. In any case the example shows how the operation of 'Cholecystectomy' (having one's Gallbladder removed)
qualifies, but 'Tonsillectomy' does not. The point of this initial part of the video is that the boolean check box is
'automagically' ticked by underlying GELLO v.1 code that has queried the Concept model (aka the Terminology) to determine
if the entered constrained SNOMED-CT procedure is a child of the concept '108189003 | abdomen excision'.
So the terminology has done the work after the field has been populated using a constrained terminology subset.
The video then more elegantly shows how past medical history diagnoses can trigger similar warnings and messages - it's all
harvested from ubiquitous and general clinical data (Information model - derived) which has then been used in a query against the
Concept model.