Stream: australia
Topic: basic problem list
Erich Schulz (Jun 04 2016 at 04:23):
I'm looking at the onto server problem list here and its making my eyes bleed...
Erich Schulz (Jun 04 2016 at 04:23):
is this really the best we can do in 2016 for a usable set of problem codes?
Grahame Grieve (Jun 05 2016 at 11:18):
that's the standard refset in the Australian distribution. And yes, that appears to be the best option...
Erich Schulz (Jun 05 2016 at 11:24):
i need a pout emoticon
Michael Osborne (Jun 05 2016 at 11:24):
You could always look at the US Problem list https://www.nlm.nih.gov/research/umls/Snomed/core_subset.html
Erich Schulz (Jun 05 2016 at 11:28):
thanks @Michael Osborne is there a public list anywhere?
Erich Schulz (Jun 05 2016 at 11:28):
lost my umls password!
Erich Schulz (Jun 05 2016 at 11:38):
many of the csiro list have explicit anatomy - so given ther3 is a FHIR condition.bodySite property these seem like low-hanging fruit to remove
Michael Lawley (Jun 06 2016 at 05:18):
um, not a CSIRO list, but a NEHTA list as part of their standard SNOMED CT-AU distribution. It's 95k+ concepts which is most of clinical finding plus a bunch of random other things - you cal explore the intersections here http://ontoserver.csiro.au:8080/refset/ (Order by Frequency will help)
Erich Schulz (Jun 06 2016 at 06:01):
thanks @Michael Lawley - when you say "order by frequency" - are you saying the frequency of use data is available? or is this just the size of the intersections? The link Michael gave included some count of institutions using the code. From a UI/UX perspective 95K terms is a disaster
Erich Schulz (Jun 06 2016 at 06:01):
2-10k more reasonable
Michael Lawley (Jun 07 2016 at 01:05):
Sadly it's not feequence of use, really it's just size of the reference set (the language cam from the original code that I re-purposed)
Michael Lawley (Jun 07 2016 at 01:08):
I'm wondering why you think 95K terms is a disaster; won't work with a picklist, obviously, but that's the point - search is the only viable option (ie FHIR terms, /ValueSet/$expand?filter=...)
The problem with 2-10K is that everyone has a different opinion on which 2-10k subset
Brian Postlethwaite (Jun 07 2016 at 02:14):
Yes, the knowledge of how "big" a valueset is helps to know which style of user interface control should be used with the valueset, radios, combo, search...
Brian Postlethwaite (Jun 07 2016 at 02:14):
(We have this issue in Questionnaire design often)
Erich Schulz (Jun 07 2016 at 05:19):
if they were truly useful terms @Michael Altmann then maybe
Erich Schulz (Jun 07 2016 at 05:20):
but have you actually looked at the list?
Erich Schulz (Jun 07 2016 at 05:21):
given that bodysite is a specific FHIR qualifier then (as is severity) then that places many as completely redundant
Michael Lawley (Jun 07 2016 at 05:25):
But this is not a FHIR-specific list, so it's not surprising that there are cross-purposes. This is just the SNOMED CT-AU problem list and there's no assumptions about the specific use-context.
Erich Schulz (Jun 07 2016 at 05:30):
but have you looked at the list?
Erich Schulz (Jun 07 2016 at 05:33):
291217007 Intentional zuclopenthixol decanoate poisoning
Grahame Grieve (Jun 07 2016 at 12:19):
welcome to snomed.
Erich Schulz (Jun 07 2016 at 12:27):
The opportunity with subsets is to subdue the madness a bit. I think Australia needs to tweak the dial down a bit more.
Michael Lawley (Jun 08 2016 at 10:10):
So, its a pretty specific concept, but why is it a problem? You should never run across it if you're not looking for it, but if you do need it, it's there for you and in a useful hierarchy for reporting/analytics purposes: http://ontoserver.csiro.au/shrimp/?concept=291217007&versionId=http%3A%2F%2Fsnomed.info%2Fsct%2F32506021000036107%2Fversion%2F20160531
Am I missing something??
Erich Schulz (Jun 08 2016 at 11:54):
i guess in the context of FHIR the very large numbers of codes with embedded anatomy is unhelpful
Erich Schulz (Jun 08 2016 at 11:55):
also in many circumstances users are expecting to find their targets in 3 key strokes
Erich Schulz (Jun 08 2016 at 11:57):
it is possible to produce a set that is ~10% of the size and covers > 95% of use cases (ok I just made those stats up - but I reckon those numbers are conservative)
Erich Schulz (Jun 08 2016 at 11:58):
it just seems no-one identified such a set in Australia
Erich Schulz (Jun 08 2016 at 11:58):
its on my todo list to get a copy of the UMLS list Michael linked to (thanks Michael)
Erich Schulz (Jun 08 2016 at 12:00):
when I started this game we had 386 lap tops and they choked on these lists...
Erich Schulz (Jun 08 2016 at 12:02):
now most of us have quad cores that hum - but i'm seriously gearing up to write an SPA that will run on a phone - so hardware is still an issue
Erich Schulz (Jun 08 2016 at 12:05):
ie this is all about getting data in - hierarchical navigation is pretty horrible for data entry
David Hay (Jun 09 2016 at 22:05):
but you can offload much of the work to the server by utilizing terminology services...
Erich Schulz (Jun 10 2016 at 10:09):
@David Hay that still doesn't overcome the basic UX issue of a ridiculous list and it is unlikely that a terminology service would be as snappy as a cached list
Erich Schulz (Jun 10 2016 at 11:30):
and I'm thinking we can do better
Erich Schulz (Jun 10 2016 at 11:31):
i think the frequency count based approach to allow dynamically shrinking and expanding the list is probably the way forward
Michael Osborne (Jun 23 2016 at 12:09):
@Erich Schulz RE: it is unlikely that a terminology service would be as snappy as a cached list. Have you seen Shrimp? It is pretty f'n snappy. You can type ahead and search the Oz Problem list in no time flat.
http://ontoserver.csiro.au/shrimp
Grahame Grieve (Jun 23 2016 at 12:26):
why? what is a terminology server but a smart device for caching lists?
Erich Schulz (Jun 23 2016 at 12:29):
Well at this stage I would be happy with anything that aligns neatly with cql
Erich Schulz (Jun 23 2016 at 12:31):
I have gotten a bit distracted by shareable knowledge artefacts... Will come back hard to ui/ux when I can embed logic in a standardised form
Donna Truran (Jun 24 2016 at 00:09):
The standard NeHTA release SNOMED Prob -Dx refset is already deployed -with all 95K terms- for an AU implementer with users on ipads, iphones and desktops, no tree-walking/navigation, type ahead search that needs only four letters (more gets better precision) etc etc etc... they love it - and had very little difficulty deploying in their own software. Same client is taking the whole of SNOMED Px refset (+65K)..... We can already boost/index the frequently terms used if the client wants - but this is not always warranted or advisable...any short listing will begin to resemble a coding cheat sheet ...and IMHO is just a bit too 1970s :-)
Erich Schulz (Jun 24 2016 at 08:13):
well more 1990's than 1970's @Donna Truran
Erich Schulz (Jun 24 2016 at 08:15):
I'd be more sanquine about the 95k list if it wasn't full of junk
Erich Schulz (Jun 24 2016 at 08:15):
NLM have got it down to 16K and that feels far more reasonable
Erich Schulz (Jun 24 2016 at 08:18):
one concrete manifestation of the innapropriate bloatage is the large number of codes with embedded site specifiers
Donna Truran (Jun 25 2016 at 00:59):
Hi there! tell me tho' whose "junk" is it? one man's meat etc.... I've just had exactly this conversation (again! and again and again) with clinicians who assert that "rare diseases add no value to the data, so we can take them off the list" Sure we can do that... but wave goodbye to research (esp emerging genomic research); what impact are we having on epidemiology? what impact on the care for patients who have actually been diagnosed with something really rare? what if someone really does need to manage the care of conjoined twins (incidence is about 1:200K); you and I might never encounter that circumstance in a lifetime of work; someone else will. Luckily size doesn't matter ;-) as long as we're not using dinky, vintage, drop down lists or tree-walking as search strategies :-) and one last small point of divergence.... what you call call inappropriate bloatage, I call analytic power... these are not just embedded site specifiers, they are logical definitions (either primitive or fully defined) and *I* need them...so we might have to agree to disagree on that one :-)
Michael Osborne (Jun 25 2016 at 03:30):
And if by "junk" @Erich Schulz you mean incorrectly modeled concepts / inappropriate for that heirarchy / some other quality issue - then by all means let the National Release Centre know about it. No one ever said the terminology was perfect.
Erich Schulz (Jun 25 2016 at 07:21):
its more a case of "codes no-one uses" (as evidenced by the NLM subset) and codes that are compound
Donna Truran (Jun 25 2016 at 07:33):
@ Erich Schulz. Can you provide evidence... a reference? a citation? of a live, deployed, in-use system? that the the NLM subset is evidence of ...what? exactly? anything? Because I am not yet convinced ... no-one can "use" codes that are not made available in the first place.... this just begs the question... we would need to compare/contrast with systems/implementations that don't subset and shortlist.....
Erich Schulz (Jun 25 2016 at 07:33):
the histology x bodysite is the most clear illustration but there are mulitple other examples
Erich Schulz (Jun 25 2016 at 07:35):
i can give you a long list of things I cant say using this list (conditions I happen to treat regularly) but would be more easiliy expressed using the FHIR site + severity value
Erich Schulz (Jun 25 2016 at 07:39):
just a quick comparision of several histological types reveals the ability to specify a site very arbitrary within the subset
Erich Schulz (Jun 25 2016 at 07:39):
but sorry not hear to be negative
Erich Schulz (Jun 25 2016 at 07:40):
i dont no who's baby this is and what the goals of it are
Donna Truran (Jun 25 2016 at 07:42):
email me Erich ... this platform isn't going to help me help you :-)
Erich Schulz (Jun 25 2016 at 07:47):
thnanks @Donna Truran I'm simply observing that this list has excess precordination in large sections while omitting common conditions and without sometype clues to aid filtering its not what I'd be starting with
Erich Schulz (Jun 25 2016 at 07:48):
i've gotten a bit distracted by a CQL transpiler so i'm building a problem list UI currently - I've been out of informatics for over a decade so I was kinda just hunting around looking at the status quo since i floated off
Erich Schulz (Jun 25 2016 at 07:49):
but I think I need onto server so will drop you a note - I'm sure you can help :-)
Donna Truran (Jun 25 2016 at 08:21):
Happy to help Erich and keen to help you from travelling down the cul-de-sacs wheere we've already been and know lead nowhere interesting :-) here: donna.truran@csiro.au
Grahame Grieve (Jun 26 2016 at 23:37):
@Donna Truran - the underlying issue is whether the national release centre is trying to build pre-coordinated reference sets or not. I know that there's a workload aspect here, but the reference sets should be clear in their design what the scope of them is, and what other elements are anticipated to be available. If htey are clear in this regard, I haven't seen any clarify
Donna Truran (Jun 26 2016 at 23:50):
@Grahame Grieve Grieve I don't disagree with you, historically there has been (here and elsewhere) an unwarranted proliferation of refsets with a lack of understanding of their purpose, scope, provenance and even their maintenance. There is *some" specification and clarity, but it's not easy to find! :-)) What's really good to see is a discussion about binding, 'cos I think this will help specify what refsets are needed/justified/reusable/shareable (or not) and might help prevent the sort of redundancy I'm seeing, where the content intersections between refsets sometimes exceed 80% and everyone thinks they'll got a better refset/subset/shortlist.... Terminology servers, along with constraint languages/techniques will make the build of new refsets less of a burden (*I hope*) :-).... My only concern is whether there is a fundamental misunderstanding between what a refset really is, and what a subset is, and what a shortlist is....and what the impacts and implications are. It's not my experience that the majority of people 'get it' (yet).
Grahame Grieve (Jun 26 2016 at 23:52):
well, I have no idea what the difference between refset, subset, and short list are
Donna Truran (Jun 26 2016 at 23:57):
It's TOO long a conversation for here :-)
Grahame Grieve (Jun 26 2016 at 23:59):
any references? It wouldn't be better to move the follow to a private disacussion
Donna Truran (Jun 27 2016 at 00:14):
no citations to hand, but I will look for you and then share. The (pragmatic) working definitions, that I find helpful are : RefSet, a prioritisation of some (SNOMED) terms via a filter, boosting, dynamic constraints (or indeed deprecating some) from within a standard corpus (perhaps one axis), where the entire corpus remains available and is considered valid. A subset is a strict enumeration of 'valid' terms only, where any term NOT in the subset is by definition NOT valid and NOT available. A shortlist - a very cut-down version of a subset, where the content is limited to what can fit on screen real estate or a drop down list for selection. This is NOT to say that subsets and shortlists don't have a place and are not warranted - they ARE of course. The challenge (and sometimes the trick) is working out which works best for what purpose.
Grahame Grieve (Jun 27 2016 at 00:15):
that's a remarkable set of definitions, given that I've only ever heard 'refset' internally to NEHTA, but where we actually mean 'subset'. Or perhaps that's my faulty hearing, not being aware of the differences
Donna Truran (Jun 27 2016 at 00:23):
It may be that *I* use them differently too :-) and it's true that some of the language used (in the SNOMED world) is a bit ambiguous and evolving..... but I'm pretty sure these are worthwhile distinctions (they make a difference - technically and for implementations). We have experience here where a vendor/custodian insisted upon a 'subset' containing only the 14K terms (enumerated) the ones they believed they only ever needed/wanted for their customers... only to implement that subset and 3 months later found themselves drowning in request submissions for the remainder of SNOMED terms within that axis (65K) and to have these boosted/floating to the top/allowing the clinical users to make their terminology choices.... And then there are the vendors/custodians who believe they only ever need the top 100 (most frequent) terms ;-)
David McKillop (Jun 27 2016 at 00:24):
@Grahame Grieve , @Donna Truran FYI - The following text was taken from the IHTSDO Implementers course Module C, presentation 4, page 2:
Subset, Reference set, Value set
:black_small_square:Subset
:black_small_square:A set whose members are all contained in another set
:black_small_square:A SNOMED CT subset is a collection of components (concepts, descriptions or relationships) from an edition of SNOMED CT
:black_small_square:Reference set
:black_small_square:A set of references to SNOMED CT components
:black_small_square:Simple reference sets are used to distribute SNOMED CT subsets
:black_small_square:Reference sets may include additional information about referenced components –so they also have other uses
:black_small_square:Value set
:black_small_square:A set of concept representations from one or more code systems
:black_small_square:Usually exist to constrain the content of a coded data element or data type property in an information model
There is no reference to a short list.
Donna Truran (Jun 27 2016 at 00:28):
fabulous David, you saved me :-) Although these definitions are limited to describing what things are and not so much about how they can be/should be used. I think this is where some of the divergence occurs, simple refsets look exactly like subsets - but this is (AFAIK) merely the distribution method and not the intent.
Grahame Grieve (Jun 27 2016 at 00:28):
umm, no wonder people are confused
Donna Truran (Jun 27 2016 at 00:35):
Yep :-) exactly... whether I'm right or not at least our internal, work-a-day conversations here make sense now (to us!) 'cos the official external descriptions of what's what weren't helping us ....:-) Wonder if Michael Lawley wants to weigh in and provide some tech input here? He'll have a way better understanding than me :-)
Peter Jordan (Jun 27 2016 at 02:12):
My understanding is that Simple Reference Sets can only be used to represent subsets of components or other ref sets. Therefore, from a FHIR terminology services perspective, they are synonymous.
Erich Schulz (Jun 27 2016 at 06:05):
strewth
Erich Schulz (Jun 27 2016 at 06:05):
not conviced these definitions are adding tremendous value
Erich Schulz (Jun 27 2016 at 06:06):
perhaps better to focus on the specific function the set in question is expected to fullfil
Grahame Grieve (Jun 27 2016 at 06:08):
I've always tha the most important long term outcome of the NCTS is to allow the community to collaborate to develop actually useful value sets, since I cannot see that the existing ones published with SCT-AU are heading towards beeing useful. But that's because it's a hard problem (Donna's original notes about the difficulty of that shouldn't be ignored - and I respect the SCT-AU team greatly)
Erich Schulz (Jun 27 2016 at 06:08):
and as to the 90K set I referenced at the start I'd be curious as to what it is supposed to be achieving
Grahame Grieve (Jun 27 2016 at 06:08):
it's primarily intended for creating discussion. like this one
Erich Schulz (Jun 27 2016 at 06:09):
i think the NLM are on the right track
Erich Schulz (Jun 27 2016 at 06:09):
heh
Erich Schulz (Jun 27 2016 at 06:09):
mission accomplished?
Erich Schulz (Jun 27 2016 at 06:11):
in terms of creating usable subsets the frequency of use data is the most maintainable approach
Erich Schulz (Jun 27 2016 at 06:11):
I am wondering why Aus is attempting to do this on its own tho?
Erich Schulz (Jun 27 2016 at 06:12):
I am certainly aware of how easy it is to drown in an ocean of ontology
Grahame Grieve (Jun 27 2016 at 06:13):
well, it's only very recently that NLM have begun to look like they're making sense. And that didn't come easily
Erich Schulz (Jun 27 2016 at 06:13):
I reckon in CSIRO or whoever it is asked NLM nicely it their set could go into shrimp...
Erich Schulz (Jun 27 2016 at 06:14):
NLM have been publishing that set for years @Grahame Grieve
Grahame Grieve (Jun 27 2016 at 06:14):
which set? stuff published through VSAC?
Donna Truran (Jun 27 2016 at 06:14):
No thanks Erich, we've moved on :-)
Erich Schulz (Jun 27 2016 at 06:16):
moved on?
Erich Schulz (Jun 27 2016 at 06:16):
(sorry i have been under a rock for last 15 years)
Erich Schulz (Jun 27 2016 at 10:44):
i guess I'm genuinely curious about what "moved on" means... because i have been under a rock for a while I'm blissfully ignorant of what's been happening in informatics
Erich Schulz (Jun 27 2016 at 10:45):
(I've been dabbling with LAMP stacks and more recently JS but not doing any health informatics at all, other than as a system using of hospital IT systems)
Erich Schulz (Jun 27 2016 at 10:48):
does "moved on" mean "we dont have any money any more" or "we've found something better to do now" or "we dont think this is important anymore" or "we told the government we've done this so it would be embarrassing to say its, erm, not done" or "we think what we have done is perfect so stop complaining" or "no one is complaining, what are you talking about?"
Erich Schulz (Jun 27 2016 at 10:50):
sorry if that is a bit provocative... few wines after a long day talking :-)
Erich Schulz (Jun 27 2016 at 10:58):
and agree completely with Grahame that this is all a hard problem - I'm just trying to get a grip on where things are up to
Donna Truran (Jun 27 2016 at 20:20):
It's fine to be a newbie and great that you're trying to catch up - and no problem being provocative either :-) But none of those things - there is no 'political' or policy issue here (AFAIK). Most frequency-based subsets were built as 'starter sets' to give people a softer entry, or to enable something else to happen (mapping for example, or migration from a DIY set to a SNOMED standard). (aside: this is also true of the NLM set.... see here: https://lhncbc.nlm.nih.gov/project/snomed-ct-core-problem-list-subset-and-rule-based-maps, and where they say "often need to be expanded for local use"). They're 'where we started', they are meant to enable adoption, and we're not likely to end there (that's what I mean by 'moved on'). If you find them helpful as a kick-off point, then that's great too.
Erich Schulz (Jun 27 2016 at 22:26):
thanks @Donna Truran I guess in that case I'm unclear as to the goal of the set I started this thread referencing.
Erich Schulz (Jun 27 2016 at 22:26):
I'm just after a "clinician friendly" list of possible problems that would play well in a FHIR context - and that set definititely isn't it.
Erich Schulz (Jun 27 2016 at 22:28):
I'll start another thread on my immediate need
Last updated: Apr 12 2022 at 19:14 UTC
