[2.60] The facility to search the Xmaps by typing in the code from an external scheme (e.g. type in an ICD code in order to find the SNOMED concepts Xmapped to it) would be easier to use if, when there was no direct match found against e.g. the code ‘abcde’ as typed, you got a pick list of matches (if any) against ‘abcde’+wildcard, possibly with any corresponding rubrics for each match pulled in from the external DB files for the relevant external schemes. This would also allow you explicitly add your own wildcards e.g. search for D136*
[2.60] Also, I’m wondering whether the search performance over the Xmaptargets might not actually be fast enough that you could avoid having to specify which scheme you’re intending to search: why not attempt to match the search string against all the known Xmapped schemes, and offer a pick list of matches, grouped by scheme? You could select one (or more?) schemes to restrict a match against if you wanted to, but would not need to be forced to.
[2.50] Ability to import arbitrary tab, comma or CRLF separated lists of concept IDs from one or more external text files into an ad hoc created domain concept subset, from where the imported list then remains persistent (until deleted) and you can then load the list into the hierarchy pane as a result set for some form of browsing/examination. Could also usefully include support for copy and paste of a list of 1-n concept IDs from
MS-Excel directly into the hierarchy pane.
[2.50] More generally, possible improved support for handling such ‘result sets’ created externally (e.g. including a list of all the codes recorded against any patients in a particular clinic) so that they can be loaded and analysed. Could include catering for result sets where individual codes can appear more than once.
[2.50] Copy/export current expanded hierarchy view to
RTF (or
HTML?) with outlining and preserving colour coding
[2.40] Apart from an expression builder that constrains users to building only expressions that comply with the concept model, there’s also a case for an expression validator that can parse expressions created elswhere for whether they comply with the concept model. Ideally should accept input either as HL7 CD Datatype or SNOMED CG notation.
[2.01.00] Suggestions for improved changelog browsing: always display all relationships and descriptions ever known to be said about the focus concept in the infopane (though only one row per relationshipID or descriptionID - don’t show the same description multiple times for each status change). The subset of visible statements representing the state of play at the global browse date (as set bottom left corner of SNOB) appears initially in normal text, whilst all other relationships or descriptions that applied only at some past or future point in time are in grey. Just below the definition section, list all the dates when changes occured in a tabular layout. Clicking on a particular date changes the infopane local date (but not the global browse date) so that what’s greyed out or in normal text changes in the relationships or descriptions sections changes to show the view of the concept at the clicked point in time. Some types of change wouldn’t be visible by this technique (e.g. changes in description status) but the most useful ones - when a description or relationship were introduced or removed - would be. The current complete changelog printout could then be an optional extra.
Concepts that have been added to or removed from a subset as originally loaded can’t easily be retrieved as a set afterwards, even though their status seems to be persistently either ‘added to’ or ‘removed from’. You can see them highlighted in their display colours within the hierarchy, but its hard to find them all if the subset is large. (Versioning and delta management will be an issue for any planned subset editor that’s supposed to be more than a toy.)
[2.01.00] In Changelog view, hyperlink dates where they appear - clicking one would refresh the info pane to show the concept at that date, without altering the global browse date. Would be useful to have a button somewhere that can be used to quickly toggle the global browse date between two dates, of which one date would always default back to ‘today’ on each start up and would be configurable to a different date only within sessions, and the other date value would be persistently configurable across sessions. (Spawned instances of SNOB would default their date button values to the current values of the spawning instance).
[2.01.00] Changelog view - Instead of showing the relationship or description IDs in bold as the item header, show the human readable forms (currently line 3 for a relationship and line 2 for a description) as the bold header, followed by the relationship ID in brackets. Also, its not really useful to sort by SNOMED object identifier. A more useful alternative to the chronological view would be to sort by identifier type (all relationships first, then descriptions) and within those sections alphasort on description name or relationshiptype.name, though this functionality might be better suited to a popup on individual elements wherever they appear in the browser.
Could SNOB display ‘inherited’ mappings for any SCT concept:S, ie either or both of (a) the complete list of crossmaps applied to any ancestor of S or (b) for each scheme with known crossmaps, only the ‘most specific’ crossmaps ie excluding those crossmaps attached to members of (a) that are an ancestor of at least one other member of (a)
The number of NOTES could grow very large, so browsing the corpus will quickly become difficult. As a first go, the NOTES viewer could group individual notes under the supercategory of the concept to which they’re attached. A further improvement would be to diplay a note relating to concept:x in a subhierarchy under the note for concept:y if y is an ancestor of x.
Scripting support for importing CLaML files.
Classifications (in ClaML) are not imported in the SNOMED database, each classification is imported in its own database. For example, ICD-10 is imported in the database icd.db. Rebuilding a SNOMED database does not destroy the classification databases, these are available for all SNOMED databases. So importing a classification is a one-time action. It is therefor not very useful to add scripting support for ClaML files.
Suggested changes to some default settings: default font: Arial Narrow. Max search concepts: 500. Show historical concepts: On. Show non-current descriptions: On. Show crossmappings: On (if loaded). Show legacy SNOMED/CTV3 descriptions if available: On. Prefix descriptions: On. Check relationships against metamodel: On (if metamodel exists). Colours: primitives rgb(64,0,64), composites (255,0,255), Attributes (0,128,255), Inactive (192,192,192), Newly (2,196,31), Removed (255,0,0). Background colour for relationships failing metamodel (255,224,196)
Please, set this up with your own setup.xml file.
