What is a Constrained Set?

• The word constrain means “to control or limit something” (Cambridge Online  Dictionary)

• SNOMED CT makes extensive use of refsets (reference sets), for a wide-range  of purposes, each of which have specific purposes

• Refsets need to conform to certain specific rules and guidelines regarding their
preparation, distribution and maintenance
• Takes a long time to design one and the designing entity needs to have a
 namespace assigned to it
• This makes the rapid and effective use of SNOMED CT in individual systems  cumbersome at best and impractical at worst


Solving this conundrum

• Since within a system it is pretty much lassiez faire or “anything goes”, it is wise  to use a Constrained Set of the SNOMED CT that suits the purpose

• For example, for gender or laterality, a small list specially created SNOMED CT code set for that purpose should work excellently (actual list follows)

• Thus, wherever there is a requirement for a system to have a list presented to 
the user for their selection, this small list serves the purpose
• This limited list is termed a “Constrained Set” or CSET (a portmanteau of the  two words that it refers to) by Dr Bhattacharyya

CSets for Gender & Laterality

Explication

• This constrained list works very well and suits the purpose of helping users to  fill in the gender or the anatomical side

• The format of expressions as per the IHTSDO construction rules states that  either of the following is acceptable (only pre-coordinated types are shown here)

• ConceptID
• ConceptID | Term|
• Thus, let’s say, for “bilateral” laterality, either of the following works

• 51440002
• 51440002 | bilateral |
• It is important to debate the merits and demerits of such an approach

• Not only must the pros and cons be considered but also the end-result should
 justify it
• For starters, let us briefly study the refset approach

• It should be noted that refsets are meant to be exchanged with external  entities in their entirety and need to be updated after every release –  international or national

• It should also be noted that by the term “system” it is meant any system that uses SNOMED CT


Refsets

• Namespace required if refsets are shared with external entities/systems

• Needs regeneration after every release

• Can be automated using pre-set scripts (e.g., SQL, Perl, etc.) that needs to be  designed in-house


Data Management

• When data is managed, it is the expressions that are stored and exchanged

• The expressions have a machine-processable part (ConceptID) and a human-readable  part (Term) of expressions or just the machine-processable part (ConceptID), it is  largely a system designing issue, which is an internal matter

• Thus, system designers only need to consider that which is necessary to capture,  store, retrieve, display, exchange, processing and querying

• Anything else is not related to the system functionalities

• Refsets have largely a governance connotation


Comparing Refsets with CSets

Benefits of CSets

Logic

• Since most of the data is required to be captured in pre-coordinated expression forms  (the form as available from international or national releases) that is either ConceptID  only or ConceptID | Term | formats, the system designers need to have access to these  for storing in their databases and used as-is

• For queries, transitive closure tables are required for data aggregation, else, either  only the ConceptID or only the Term need be used to return the proper records

• The CSets are easy-to-create being mostly built on-the-fly and hardly taking more than  an hour to create moderately complex ones, provided the right domain experts are  available to guide the designers


Method

• A good SNOMED CT tool like ClinClue® or Snow OWL® is required

• A terminologist would be ideal but it may be tough for system vendors to hire

• The next best person to do this type of work is a health informatics professional who  familiar with SNOMED CT

• Alternatively, the following may be considered as a team since this type of work
cannot be done by one person, it will be too error-prone and consequently risky
• Someone familiar with the tool being used is usually acceptable

• Someone well-conversant with SNOMED CT as a whole is required

• A good DBA who can design the database in such a manner that duplicates are  removed – the way SNOMED CT is modeled, the same term may be present in  different hierarchies

• A domain expert – specialist, doctor, nurse, dentist, paramedic, etc. – is  required to identify all Terms (preferred as well as synonyms) required for that  domain (clinical finding, procedure, disorder, allergy, etc.) to ensure that all  the necessary terms (both preferred and synonyms) have been incorporated

• During system use, only the Terms are displayed while the ConceptIDs are  stored and/or exchanged with or without the Terms, with the Term to  ConceptID-to-Term mapping done at the API level
• The best way is to identify the Term that best describes the domain concept  (marital status, laparoscopic procedure, lipid profile, etc.) and construct the  SQL statement that will extract all the necessary subtype children and  descendants, which will form the required constrained list of values

• For maintenance purposes, rebuilding the CSets for every subsequent official  release of SNOMED CT, which happens every six months, can be automated by running these scripts to build a new CSet

• The need to manually check the CSet does not go away though to ensure that  all the required concepts and their corresponding preferred terms as well as  synonyms have indeed been incorporated



CSets Types

References

1. Matter based on ideas formulated by Dr SB Bhattacharyya
 
2. Some matter sourced from presentations prepared by Dr Karanvir Singh in
 consultation with IHTSDO on behalf of National Release Centre, India
3. IHTSDO – http://www.ihtsdo.org/snomed-cta
4. National Release Center, India – https://www.snomedctnrc.in/ 
5. What is SNOMED CT – http://www.ihtsdo.org/snomed-ct/what-is-snomed-ct