I need to implement the access for various terminologies, included the OpenEHR terminology.
I’ve derived a class model from the openehr_terminology_en.xml but it seems this model is not compatible with the API proposed in support_im.pdf
As an example, in openehr_terminology_en.xml, “terminology” is the only element that has a language, but in support_im.pdf, the CODE_SET_ACCESS class has an operation has_lang( lang ), but the code sets have no language to do this search. I have a question here, is it correct that a code set have a language? and code sets and codes are not language independent?
I think the only “language-dependent item” is the description of the code, so I think that both openehr_terminology_en.xml and support_im.pdf have some bugs to fix, is it correct?
And here are questions based on my ignorance, what’s the difference between Group and CodeSet? and what’s the difference between Code and Concept?
I need to implement the access for various terminologies, included the OpenEHR terminology.
I’ve derived a class model from the openehr_terminology_en.xml but it seems this model is not compatible with the API proposed in support_im.pdf
As an example, in openehr_terminology_en.xml, “terminology” is the only element that has a language, but in support_im.pdf, the CODE_SET_ACCESS class has an operation has_lang( lang ), but the code sets have no language to do this search. I have a question here, is it correct that a code set have a language? and code sets and codes are not language independent?
I think the only “language-dependent item” is the description of the code, so I think that both openehr_terminology_en.xml and support_im.pdf have some bugs to fix, is it correct?
And here are questions based on my ignorance, what’s the difference between Group and CodeSet? and what’s the difference between Code and Concept?
The AE terminology file has been floating around since the dawn of time. Tim Cook has pointed out that it has languages, countries, terminology names as well as openEHR codes and interface terms. The Java group have put a simpler model together. It would be nice if we had a terminology file that did pool all the core terminology required by the reference model and archetypes as this simplifies implementation.
I would be pleased to encourage a discussion on the best way forward for this.
Certainly in the description, it explains the openEHR Terminoly as those
codes that are missing from form specifications. However, country and
language codes are very well expressed.
The ARB (as I have suggested before) needs to revisit the openEHR
terminology.
In the Python implementation we are most certainly bypassing
openEHR.Terminology. We have no choice in REAL WORLD applications.
When I saw the API and the structure of the openehr_terminology_en I thought “something is wrong here”, then I see the Java Ref Impl of the mini termserv with your comments about methods that can’t be implemented with this terminology model, here I think “I’m right”
If you want we can discuss the topic on the mail list or on the wiki, I think we can correct the model in a few weeks, making an implementable and usable model/API.
