Bert, the terminology interface defined in the openEHR Support IM specification is minimal, and is designed only to support the semantics of the rest of the specification; it is not trying to be a full terminology service by any means. Many other functions could be added, but in fact a different design would probably be used. The classes used in the spec only ensure that the rest of the specification has a simple access to terms. Mainly it is needed to ensure the validity of the invariants, which restrict coded attributes to being from certain code-sets or groups.
There are many terminology products and service interfaces are available for some. The forthcoming openEHR virtual EHR API will include some of these. - thomas Bert Verhees wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rahil Qamar schreef: > >> Hi Bert >> >> >> Bert Verhees wrote: >> >> >>> It is not that problem. There is a terminology-interface, below, you >>> can do whatever you want. Webservices/databases, everything is possible. >>> >>> My problem is in the interface itself >>> >> Which terminology interface are you referring to? Some interface >> available in the Ocean Editor or the one developed by the Swedish team? >> > > I was referring to the interface which is described in the support-PDF > > >>> , which seems to me not sufficient, but maybe I misunderstand, that is >>> why I ask. >>> >>> Because the interfaces speak of codes (in codesetaccess and >>> terminologyaccess), presented in codephrases. I don't know how to >>> understand this. >>> How can I present f.e. a description with a code, when only the code >>> itself is presented in the interface in codephrase-form? >>> if it was in codedtext, I would be possible to add termmapping which >>> would be something more, but even in codedtext it is not possible to >>> add a description. >>> >> Well the blood pressure archetype uses a "Pressure" code i.e. "125" from >> the openEHR terminology. However the rubric is not attached as either a >> description or name anywhere in the archetype model. Is that limitation >> what you are referring to here? It would be more helpful to explain your >> problem with the help of an example. >> > > Regarding to CodeSets: > There are many codes which are attached to description, and that is > where my problem was. For example language "en" means "English". > It is, in my opinion, not possible to use the terminology service, as > described in the specs, in an application. > To stay with the example, suppose you want to let someone choose a > language, it is only possible to show the codes when using the > terminology service, it is not possible to show the description. > > > This is also a straight forward example. > > As it works now, it is more a translation service, which is also very > useful, but it could be more then that. Many terms are very straight > forward in meaning, but some are not. Because why would you want to > translate "unknown", if you don't know what is meant with it. It may > well be that "unknown" in Turkey is something complete different from > "unknown" in England. > For this reason it is good that a terminology Service is able to explain > what it means: "A possible value exists but is not provided." > > This is under null_flavours. There are also mappings known (in this > case: HL7_NullFlavor::V10612), which would also be good to show on > demand or for automatic processing. > > In this case, the terminologyservice from the specs is not able to help > out here, because only a CodePhrase is offered to contain information, > which can only contain the code-itself, and the terminologyID. > > If instead DvCodedText was specified as container to store terms, then > it would be possible to store termmapping. And not only thi, but also > characterset and language. > So, this is one thing I don't understand. Why are CodePhrases used to > contain terminologies, and not DvCodedText? > Also, in my thinking, I would like to extend DvCodedText to > DvCodedTextEx, containing also a Description of what is meant with a > terminology. > > I hope I made my questions clear. > > Since this morning, the email from Thomas, I understand, you also > confirm this, the terminology service is only for use for the > openehr-terminology. I must have missed in the specs. But it helps, > because I was afraid to use a own defined terminology service, because I > was afraid to miss the mainstream from the specs, and have to reverse my > development. > So it explains, but not why the openehr-terminology is modelled as it is. > > Bert > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org > > iD8DBQFF8x5hsr/NIrczD3MRAmcwAJ9dGG8wvIjFHTVjXbAdL/z+cKyFnQCeI84G > d8Lyo0xjPJC6PsztndUntmU= > =2Iif > -----END PGP SIGNATURE----- > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > -- * Would you vote for a politician who has not responded to An Inconvenient Truth <http://www.climatecrisis.net/>? * */Thomas Beale/* CTO Ocean Informatics <http://www.OceanInformatics.biz>, Chair Architectural Review Board, /open/EHR Foundation <http://www.openEHR.org> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk> _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
