You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 :) )
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 install
ed to an Opal application using requirements.txt, using the existing Django mechanism for managing dependency versions.The text was updated successfully, but these errors were encountered: