...

1. The UI should be customised to the use case, e.g.
   • The UI requirements for data entry at the Point of Care are different to a SNOMED CT browser.
2. Text searching should be flexible, e.g.
   • Allow the user to search by partial matches. Searches should ignore the order of terms. Other normalizations of a search term can be applied in specific use cases.
3. Synonyms should be used to improve searching and selection
   , e.g.
   
   • The search term should be matched against all acceptable synonyms in the given language dialect (only for concepts in the relevant value set)
   • e.g. Only the preferred term should be displayed in the result list (a) to reduce the length of the result list, and (b) to ensure that the meaning of the concept is clearly represented
4. The display order of the results is important, e.g. 
   • A common technique is to order search results with the shortest matching term first. Other options, like displaying frequently used concepts earlier in the list, should be considered.
5. Structured data controls can be applied to support effective data entry and ensure consistent use of concepts, e.g.
   • Use suitable Using appropriate data controls, such as check boxes, drop-down lists or search fields, can simplify the use of SNOMED CT for specific use cases
6. Data entry should be constrained for each specific data element using ECL queries, reference sets or other filtering mechanisms., e.g.
   • A 'Procedure' field may be constrained to only allow subtypes of Procedure (i.e. < 71388002 |Procedure|) to be entered.

...

• Only SNOMED CT terms are displayed on the UI (i.e. no identifiers are shown)
• Searches supports support partial term matching in any order - e.g. "asth alle" matches "allergic asthma"
• Searches are responsive - i.e. search results are adjusted dynamically as the user types more letters into the search term
• Searches can match on any synonym in the given language dialect - e.g. "heart attack", "infarc heart", or "card infarc" will all find 22298006 |Myocardial infarction|
• Only the preferred term of matching concepts is displayed in the result list - e.g. searching on "heart attack" will display "Myocardial infarction" in the result list
• Results are ordered with the concept associated with the shortest matching synonym first. Note that the length of the preferred term displayed is not considered; only the length of the synonym that matches the search term.
• A 'boost' feature is provided that increases the prominence of a selected set of concepts. This can be used to promote frequently used concepts, thereby reducing key strokes for data entry - e.g. searching for "diabetes" with the 'boost' feature turned on will move 'Type 1 diabetes mellitus' and 'Type 2 diabetes mellitus' higher in the result list.
• Search fields are constrained using dynamic ECL queries - e.g. a search for "appen" on the diagnosis field will match "Appendicitis" (< 404684003 | Clinical finding |), while the same search in the procedures field will match "Appendectomy" (< 404684003 |Procedure|)
• The UI uses the MRCM to validate inter-field dependencies - e.g. Only procedures that (a) have a |finding site| value that is a member of the Lateralizable body structure reference set, and (b) do not already have a laterality applied within its definition, are allowed to have a laterality (e.g. 'Left', 'Right') assigned by the user in the 'Laterality' field. If the selected procedure already has a laterality applied to its definition, then this value is auto-populated into the 'Laterality' field.

For more information, please refer to the following links:

• Search demo: http://snomed.org/ui 
• Demonstration guide: https://github.com/IHTSDO/snomed-ui-examples/.../Appendix A
• Source code: https://github.com/IHTSDO/snomed-ui-examples

Other User Interface Demonstrators

...