search

rcpch / rcpch-audit-engine

Epilepsy12 Audit Platform
https://e12.rcpch.ac.uk/
GNU Affero General Public License v3.0
5 stars 5 forks source link

Add SNOMED-CT codes to all the terms in COMORBIDITIES #10

Closed pacharanero closed 2 years ago

pacharanero commented 2 years ago

@coldunk can you link to the SNOMED RCPCH curated list here please. Also the work you've already done mapping these SCTIDs to a Comorbidity, can you upload it here? We may want to create a re-usable list in another repository, to enable this being shared as a Python package

coldunk commented 2 years ago

Thinking should link to live snomed ct browser neurodis refset

eatyourpeas commented 2 years ago

I have added to a docs directory in the main repo. I have also spent some time implementing Hermes from the remarkable @wardle which I envisage running as a local SNOMED server to supply the look up values.

coldunk commented 2 years ago

I am beginning to think this 'look-up engine + APIs' turning clinician-worded diagnoses into validated 'properly-worded' digital entities is 'the thing'. Trying to think what that 'digital entity' would comprise of. Think is an entity that means the same thing in the clinical world as the digital world! As well as the engine 'serving' our audit dataset, could serve other things?! Going to look up some Java-based work I did with karen h/and prayle in 2016 that got the snomed ct neurodis refset work started. Mulling!!

wardle commented 2 years ago

Thanks. I am generally defining my code lists using the SNOMED expression constraint language. For example, one can test membership, or expand a valueset of "<< 128613002" and get all seizure disorders. I also build ECL on the fly from either ICD-10 or ATC codes. You can see what I've been doing for an MS project if you like - I am building code lists declaratively using a union of all three depending on need - e.g. see the medications and diagnoses listed from line 33 of this project-specific code.

Glad you got hermes working. I am now layering more complex abstractions above hermes, and my dm+d implementation - e.g. see a more generic 'code lists' abstraction that basically has inclusions and exclusions specified as a mix of ECL, ICD10 and ATC. I am planning on spinning that out into its own service, so code lists on demand - a bit like Ben Goldacre's code lists project but derived computationally rather than curated manually.

So I would not advise keeping a manual list of SNOMED identifiers, but leverage ECL, either directly or indirectly, in order to build your code lists. I'd also look very carefully at expanding those code lists to include historical associations, as you will be surprised that now deprecated concepts will not be included unless you do. See https://wardle.org/snomed/2021/07/26/making-valuesets.html

eatyourpeas commented 2 years ago

So this is now working in no small point thanks to you @wardle thank you. url if you want to use is here . We also have an instance of deprivare running here We are very grateful and I am still up for that chat? Closing this issue here though.

wardle commented 2 years ago

Glad it is working. Let me know if any issues. I'll email about another meet-up!

You should also see how graph APIs work across these datasets. Composing functionality with data in a unified graph with independent resolvers provided by different subsystems and services is a super power to building compelling user interfaces. 😀

wardle commented 2 years ago

PS. You might also see https://github.com/wardle/dmd which runs a tiny micro service to provide access / resolution to the UK dm+d and address your #24. It composes nicely with SNOMED because of course they share common identifiers. The key to the graph above - so I walk from SNOMED into dm+d and get ingredients and then walk back to SNOMED to understand those ingredients, for example. The concrete values present in dm+d also help in supporting roundtripping between product-based, and dose-based prescribing, or simply calculate daily dosages in terms of ingredients, for charting.