New to the forum, but wanted to summarize several conversations between myself, Christian Reich, Frank deFalco and/or Joseph Finkelstein comparing Hermes interface to the terminology browsing and querying infrastructure at Columbia, reconciling both with common use cases, and future directions. Christian, apologies if some of this repeats posts you have made elsewhere.
- Hermes is a powerful browsing tool for vocabularies (Great work, Frank). It bears many similarities to tools developed at Columbia University for browsing the local medical entities dictionary (the MED), including a concept-oriented frame view, with visualization of relationships and navigation, and it has some advantages such as advanced filtering.
- While Hermes is a single access point, Columbia has 2 distinct tools, one a visual browser, the other a command line query tool for generating lists.
- Hermes, for the most part, “can do it all” already for the savy user, but there are few items we discussed in the comparison for future directions. Most centered around bringing some natural use cases out into native view (vis-a-vis hidden under advanced query options).
- Visualizing hierarchy: Seeing the hierarchy is a key use case of terminology content access. Hermes does provide hierarchical relationships in a list with other relationships, but seeing parent and child concepts distinctly and visually is often very helpful. As one possible direction, the Columbia tool shows the flow of the hierarchy in the left panel with other relationships on right.
- Quick access for common use cases: At least from our experience, users of terminology content range from EHR systems with real time connections to researchers, data analysts, infection control systems, billers, etc. Each may have their own set of use cases for what they require from a terminology server, but those use cases may share common query logic. As a result of this, we discussed:
a. Pre-building common filters into the application (such as descendants+attribute type).
b. allowing individual users to preserve filters they commonly use.
c. Examples could be "Please give me all SNOMED codes for any kind of knee disorder”, “Please give me all LOINC terms measuring sodium”, “Please give me all drug preparations containing propranolol”, and many other examples we can add. Some of these may fit case a), some case b). - Other things for future discussion:
a. Generate exportable lists, (and lists greater than the present 100 per page limit.)
b. Whether more complex queries should be incorporated in the browser is open to discussion (such as unions, intersections, etc).
c. Advanced filter presently applies to relationships. Perhaps it could be intuitive to apply same filter frame to search results, instead of the entry question “Standard vs non-standard”.
d. It seems many of Columbia’s qrymed commands are already well-accomplished by Hermes, perhaps consider a few of the others such as idesc, ianc (desc and ancestors including present concept) (we can discuss).
e. Incorporation of definable attributes into the data model (not really a Hermes thing).
Looking forward to working further with the Hermes development team!
David Baorto, MD, PhD
Columbia University DBMI
NYP Hospital IT