terminology

[system]

Hi,

I hope this is a stupid question, and people can overload me with information.

I am trying to build a terminology-service, but because I want to conform as much as possible to the specs, I try to understand them.

I have a few questions:

we have the openehr-terminology, like this: (excuse me for using html-table)

Terminology: openehr
Group_name(“en”): “attestation reason”
Concept_id	Rubric (en)	Description (en)	Mappings
240	“signed”	The attested information has been signed by its signatory.	HL7_ParticipationSignature::10284
648	“witnessed”	This attested information has been witnessed by the signatory.

And I have the TerminologyAccess-class.

I cannot get them fitted to each other. I have the latest documentation, but I cannot find a way to fit above table-information in the terminologyaccess-class.

I figured out following, which is probably wrong:

The terminologyAccess class, to my information has mapping to table above
id → terminology:openehr
set codes
codePhrase has following
terminologyID → same as above → terminology:openehr
codestring → rubric (?)

Whereto do I map the rest?
The mappings, the description?

[system]

I found it out, partly, myself. The document
RC1.1/publishing/architecture/computable/terminology/Terminology.xsd.html
(in my local copy of the repository) was very helpful.

I, now, more or less understand the structure of classes which form the terminology.

Please correct me if I am wrong.

It all boils down to the concept/language which will be represented in the terminology-access.

This looks like this

id: String
all_codes: Set<CODE_PHRASE>
codes_for_group_id (group_id: String): Set<CODE_PHRASE>
codes_for_group_name (name, lang: String): Set<CODE_PHRASE>
rubric_for_code (code, lang: String): String

So, the groups (grouper) are visible in Group_id, which can be retrieved by querying the OPENEHR_TERMINOLOGY_GROUP_IDENTIFIERS Class.

The openehr terminologies are all in the file terminology.xml, organised in the structure which is described in the above html-file. This is very good.

There is one minor problem, the group_id’s in the class do not sync 100% with the group-id’s in the xml-file.

Here is a question
Which one will prevail, that from xml, or that from PDF?

I found out, that there are some codes which have a structure that does not fit in terminology_access, because they have more “fields” like territory and terminologyidentifier, mediatype.
How to handle these?

Finally, there is the property-unit-propertyuntit structure. It looks like, but I am not sure, that these are for, I can guess. But maybe my guess is wrong, the terminolgoyaccess class does not offer space for properties.
How to handle these, what are these for

Thanks for your attention

Bert

[Rahil]

Hi Bert

I had a read through your posting. I have one query though. Which terminology are you planning to use? The openEHR terminology is very small and limited in scope and content which makes it fine to be available in the current Terminology.xml file. However if you are planning to use one of the larger, more widely published and used terminologies such as SNOMED CT, LOINC, ICD, NANDA, and the rest, you might run into problems with trying to convert the terminologies to the XML format used for the openEHR terminology. How are you planning to handle relationships and concept definitions using the present XSD?

I might have caught the wrong end of the stick but on initial look this is what came to my mind.

Regards
Rahil

Bert Verhees wrote:

[thomas.beale]

Rahil Qamar wrote:

Hi Bert

I had a read through your posting. I have one query though. Which
terminology are you planning to use? The openEHR terminology is very
small and limited in scope and content which makes it fine to be
available in the current Terminology.xml file. However if you are
planning to use one of the larger, more widely published and used
terminologies such as SNOMED CT, LOINC, ICD, NANDA, and the rest, you
might run into problems with trying to convert the terminologies to
the XML format used for the openEHR terminology. How are you planning
to handle relationships and concept definitions using the present XSD?

I might have caught the wrong end of the stick but on initial look
this is what came to my mind.

Yes - the openEHR terminology is just a (small) support terminology for
the reference model, not a clinical terminology. Although it is probably
good to be able to access openEHR support terms in the same way as
Snomed or Loinc terms, we need to be aware:
* I only specified a minimal Terminology access service interface,
simply for teh purposes of making the openEHR specs correct;
* there will be significantly more complexity in the interface to bigger
terminologies; for example we have implemented a terminology server that
handles Snomed, ICD etc - it is a lot more inivolved than the simple
interface specified in the openEHR RM.

- thomas

[system]

Thank you Rahil, for replying.

Rahil Qamar schreef:

Hi Bert

I had a read through your posting. I have one query though. Which
terminology are you planning to use? The openEHR terminology is very
small and limited in scope and content which makes it fine to be
available in the current Terminology.xml file. However if you are
planning to use one of the larger, more widely published and used
terminologies such as SNOMED CT, LOINC, ICD, NANDA, and the rest, you
might run into problems with trying to convert the terminologies to
the XML format used for the openEHR terminology. How are you planning
to handle relationships and concept definitions using the present XSD?

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 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.

So my guess is that there has to be something more. As you can see, I am
confused here.

Maybe this is not specified on purpose?

I don't know.

I imagine the use of terminology access as following:
f.e. filling a listbox in an application, presenting codes and
accompanying descriptions so the user can choose his code. But this does
not seem possible with the currently terminologyaccess interface.

But again, thanks for your reply, and if you, or someone else can
explain where I can find additional specs, or can give explanations I am
very grateful

Bert

[system]

Bert Verhees schreef:

Thank you Rahil, for replying.

Rahil Qamar schreef:
  

Hi Bert

I had a read through your posting. I have one query though. Which
terminology are you planning to use? The openEHR terminology is very
small and limited in scope and content which makes it fine to be
available in the current Terminology.xml file. However if you are
planning to use one of the larger, more widely published and used
terminologies such as SNOMED CT, LOINC, ICD, NANDA, and the rest, you
might run into problems with trying to convert the terminologies to
the XML format used for the openEHR terminology. How are you planning
to handle relationships and concept definitions using the present XSD?
    

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 seems to me not sufficient,
but maybe I misunderstand, that is why I ask.
  

I guess, because in three days I get no anwser, the implementation of
Terminology is not a part of the public specification. This means, for
now, every one will do it in his own way.

I found some example-implementations, on forgotten spots on the openehr
website and in the archetype-editor from Mattias Fors and friends.

So I have some inspiration to go on.

Thanks for your attention

Bert

[Rahil]

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?

, 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.

However just as a starter, it is quite straight forward to establish a
query interface which goes away and extract the rubric assigned to a
terminology code to help with the mapping exercise. However this is only
for reference purpose. Because once a code has already been assigned to
a local term it is "assumed" that the mapping has already been completed
for that term. Performing a second round of mapping unless it is with a
different terminology is not beneficial.

I think what you want to do is perform mapping to other terminologies
(which should really be besides the openEHR terminology), in which case
you can always present the codes and rubric at the same time to help a
person reach a decision on the most appropriate code to map the
archetype term to.

Which example terminology implementation in the Swedish Archetype Editor
have you looked at? Also it is still not clear what exactly you are
trying to achieve through the openehr terminology? You might get more
responses if you can exemplify your problem statement.

Regards
Rahil

[system]

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

[system]

Tom,

The ‘we’ in the text below is Ocean Informatics, is it?

What will end up in the openEHR specs?

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

[thomas.beale]

Gerard Freriks wrote:

Tom,

The 'we' in the text below is Ocean Informatics, is it?

What will end up in the openEHR specs?

I believe we will publish the interface to it at some point.

- thomas

[Sam (Sam Heard)]

Hi Bert

The CODE_PHRASE is the space for keeping the link from the DV_CODED_TEXT (or any other coded information) and the terminology from which it has arisen. The text of the DV_CODED_TEXT (inherited from DV_TEXT) is where you display what the terminology provides as text in that language for that code. These have to be in tune.

If the user edits the textural display then the CODE_PHRASE can only be a TERM_MAPPING, as the code_string is no longer defining of the text.

Ocean’s terminology server (which provides access to LOINC and SNOMED with ICD_10 on the way) has a well developed service interface. Hugh Grady will provide documentation for this as it works with the Template Designer - it is based on CTS but has a different approach to meet the needs of archetypes. There is a CTS (Common Terminology Service) specification from HL7 - which is moving to version 2. Russel Hamm is the guru.

I hope this helps, Sam

Bert Verhees wrote:

[thomas.beale]

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:

[system]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Bert<br>
<br>
The CODE_PHRASE is the space for keeping the link from the
DV_CODED_TEXT (or any other coded information) and the terminology from
which it has arisen. The text of the DV_CODED_TEXT (inherited from
DV_TEXT) is where you display what the terminology provides as text in
that language for that code. These <i>have</i> to be in tune.<br>
<br>
If the user edits the textural display then the CODE_PHRASE can only be
a TERM_MAPPING, as the code_string is no longer defining of the text.<br>
<br>
Ocean's terminology server (which provides access to LOINC and SNOMED
with ICD_10 on the way) has a well developed service interface. Hugh
Grady will provide documentation for this as it works with the Template
Designer - it is based on CTS but has a different approach to meet the
needs of archetypes. There is a CTS (Common Terminology Service)
specification from HL7 - which is moving to version 2. Russel Hamm is
the guru.<br>
<br>
I hope this helps, Sam<br>

Thanks, Sam, it sure gives some places to look at.
The only remaining problem will be that I will write a terminology-service
on my own, because I need it, and good or bad, but probably not in sync
with further developments on OpenEhr-specs.

But that is where we have versions for, isn't it?

I didn't know about CTS, I will look at the HL7-site to find more information

regards
Bert Verhees

[system]

Let me resume the discussion about this subject from last few days:

The terminology service, as defined in openehr is, as I understand, not
suitable or meant for generic codeset-interface. It is more or less
special for Openehr-terminology.
Thomas mentions, writing a terminology-service costs several man-years.
I know, if you build it with all rings and bells, it is a huge system.
However, this is not what I am looking for.

I just want to implement some simple codesets, used in the Netherlands,
in almost all GP-information-systems.
For example Z-index contains coding to pharmacy, and ICPC-like coding,
there are some more small things (small in complexity, not in number of
items, the Z-Index is large)

I am not looking for ways to store or retrieve the codes. There are many
ways possible hidden below interfaces. There I don't expect problems.

What I am looking for is recommendations for interfaces to present the
codesets, in a way that in the future it will be as easy as possible to
connect to existing or planned code-systems.

Thanks for any suggestions

Bert