Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lookuplists should have SNOMED-CT mappings #43

Closed
pacharanero opened this issue Jan 15, 2018 · 1 comment
Closed

lookuplists should have SNOMED-CT mappings #43

pacharanero opened this issue Jan 15, 2018 · 1 comment
Assignees

Comments

@pacharanero
Copy link

One of the criticisms that 'proper informaticians' would have of Opal is that it does not use any standards for coded data. As a way of addressing this, it should be possible, as a starting point, to SNOMED-CT-ize the lookuplists, choosing the closest available SNOMED-CT concept for each item in the lookuplist. A lot of work has already gone into synonyms in SNOMED.

Thought should be given to modularizing the lookuplists (splitting them out from the few large .json filed they are currently in) and placing the .json files in a separate repo, with a predictable namespace convention, so that they might gradually become a useful resource for other projects, and be easily navigable by name, version etc.

The relevant lookuplists should be pip installed to an Opal application using requirements.txt, using the existing Django mechanism for managing dependency versions.

@davidmiller
Copy link
Member

davidmiller commented Jan 16, 2018

This has been on the roadmap since forever and we've talked through implementations a few times...

As a first set of incremental gains, allowing the annotation of lookuplist values with a {coding_system: "", identifier: ""} pair would be a very sensible move. You'd add a CodedIdentifier model or some such, and update the serialization/loading of lookuplists, extending the JSON format to include identifiers.

Moving our licence-clear 'live' lists into a few separate files e.g. conditions in conditions.json with those mappings would get us to a point where you could mix and match with your own on a fairly granular basis.

I would be very tempted to have these as a core plugin at opal.core.referencedata and then have that installed by default when you scaffold a new application.

As for namespacing, separate repos, packaging etc...
It's not like I'm against it - in fact one of my original long and complicated plans involved it - but I'd want to do steps 1-3 first and then reassess.
(Not to mention find some actual projects that wanted to use things and understand their needs or requirements :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants