text and description

Technical (archive)
1

Hi,

In openEHR there are two labels ‘text’ and ‘description’ used.

For instance

text = “Increased bowel sounds”
description=“Bowel sounds are more intense than normal”

In the tools I have tested ‘text’ is used as a label to input fields.

To me it would have been more natural to have 3 items, let’s say ‘term’, ‘text’ and ‘description’ where term could be some agreed
upon language independent code and text and description are localised into different languages.

I guess this has been considered, but my question then is if something like this was considered what were the reasons for discarding
such an approach?

Regards

Olof Torgersson

2

Hi Olof

This is exactly how openEHR works. If you have a look at the underlying adl for the archetype you will see that each semantic element is assigned an ‘at’ code which is your idea of a language independent term. The text and the description that is shown in the tools is actually in a language based ontology section in the adl and each archetype can have one or more languages in its ontology. Archetypes themselves have no language primacy and there are now many archetypes that have multiple languages.

If you are using the openEHR clinical knowledge manager (at www.openehr.org/knowledge) then you can set the language that you want to view the archetype in. The Ocean archetype editor allows you to view archetypes in different languages as well and translate the archetypes as I assume does the Java AE. In the Ocean editor, there is a Language menu where you can add a new language or select to view one already present. An example to look at is the Blood Pressure archetype that already has a number of translations.

regards Hugh

Olof Torgersson wrote:

3

Hi Olef,

The text is the Node name, the Description is simply a more detailed explanation of the meaning of the node. Further term bindings are indeed possible…

In the Archetype Editor, have a look at the Details tab and then at the “Node meaning in Terminologies”. It is possible to bind one or more external terms to any local term in openEHR- this is a quick way of binding the node name.

Also look at the Terminology Tab near the top of the screen, then Term Bindings, where any local text term can be bound to a single external term. It is also possible to bid any local term to an external termset via the Constraints tab. In the absence of any universally agreed formal method of describing termsets, this currently uses a descriptive ‘placeholder’ e.g is_a Cardiac Disease.

Have a look in the Reference model specification for the DV_TEXT type for more detailed information on Term binding, constraints

http://www.openehr.org/releases/1.0.1/architecture/rm/data_types_im.pdf

Cheers,
Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com
BCS Primary Health Care Specialist Group – www.phcsg.org

2008/11/25 Olof Torgersson <oloft@chalmers.se>

4

Thanks for your reply. I’ll check your hints.

A more concrete version along the same lines. I have a system developed for the domain of oral medicine during a number of years. During this time the clinicians involved have agreed upon names for various terms (corresponding to node names I believe).

For instance Mucos-txtur denotes the pattern of reaction of the oral mucosa and has a set of possible values defined by the clinicians.
On screen Mucos-txtur is not displayed, but a suitable phrase in natural language.

When modelling the same information in openEHR I would like to keep the name Mucos-txtur, but if I do that it will be displayed on screen
in both the archetype and template editor as the label for the input field. While this can be changed in the template editor it is not really a
nice solution.

regards

Olof

25 nov 2008 kl. 23.53 skrev Ian McNicoll:

5

Hi Olef,

I would regard 'Mucos-txtur 'as part of a local terminology and the best way to handle it would be by binding this code to the natural language term of the archetype node name.. i.e ‘Mucosal Reaction’->Mucos-txtur.

I am not sure of the technical/governance arrangements for using such local terminologies with openEHR - can anyone advise?

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

2008/11/25 Olof Torgersson <oloft@chalmers.se>

6

Hi,

Thanks for your reply.

To explain further, our clinicians are used to working with data in Excel/SPSS and our own visual data mining tool.

Then they compare values for different patient groups for terms/attributes/variables like Mucos-txtur.

Displaying real names of nodes like
/a/b/c/d[at0033]g/h, would not be understandable for clinicians. Displaying the rather descriptive phrases used for ‘text’, like
‘Reaction pattern of the oral mucosa’ would not be good either. A short agreed upon would be better.

I have not yet been able to investigate if what you suggest is possible to achieve

Regards

Olof

26 nov 2008 kl. 01.43 skrev Ian McNicoll:

7

Hi,

Thanks for your reply. I’m aware of the at-codes and that archetypes can (and do) exist in multiple languages.

However, this means that a term/attribute/variable ( or whatever you call the parents of actual data-items) have names like
/a/b/c/d[at0033]g/h, which are not understandable for clinicians.

Now imagine that you want to analyze some clinical data using Excel, SPSS, or some visual data mining tool. Then one does not want to display at-codes, and displaying the rather descriptive ‘text’-phrases is not optimal either. It would be better to have a short agreed upon name.

Regards

Olof

25 nov 2008 kl. 23.47 skrev Hugh Leslie:

8

Does the data originally come directly from an electronic patient record or are the clinicians entering the data at a later stage purely for analysis purposes

Can you email me a sample of a data collection form or screenshot so I can get a better idea of the process? I am not sure if this list will accept attachments - if not you can email me directly.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

2008/11/26 Olof Torgersson <oloft@chalmers.se>

9

Hi Olef,

As well as being bound to multiple languages, the at-codes can be bound to terms from external terminologies such as ICD or SNOMED. It is this sort of term-binding that I think mirrors what needs to be done in your case.

The issue that I do not fully understand is how this might work with a locally defined terminolgy like yours, rather than a terminology formally registered with UMLS.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

2008/11/26 Olof Torgersson <oloft@chalmers.se>

10

Hi Olof,

I think that you mix the archetypes’ (and reference model’s) description of the data storage format and the display format too much.

I don’t think that Ian mean that you must show either ‘/a/b/c/d[at0033]g/h’ nor ‘Reaction pattern of the oral mucosa’ for the users. The idea is instead that your Excel/SPSS export module or the visual data mining tool combine the at- or ac-codes in the archetypes with the terminology bindings to your local terminology. The benefit is that in this case we can for example use the same archetypes and you can view the data with your locally agreed short terms in Västra Götaland and I can view the data with Descriptions from a SNOMED CT Subset/RefSet containing short Descriptions.

Regards,
Mikael

11

Hi,

I’m not sure if I’ve managed to explain my question. I’m not asking for how to name actual values but the parent node of data values

For instance, in adl it could look like this (selected rather randomly from an archetype)

ELEMENT[at0001] occurrences matches {0..1} matches {
values matches {
DV_BOOLEAN matches {
value matches {true,false}
}
}
}

[“at0001”] = <
text = <“Present”>
description = <“Clubbing is present or absent”>

What I’m looking for is a way to name [at0001]. If this can be solved by a binding to a local terminology, then that’s very interesting.

My new question then becomes - how can I do this?

Regards

Olof

26 nov 2008 kl. 13.38 skrev Mikael Nyström:

12

Thanks Olef,

That is very helpful. Would it be possible to send a further screenshot showing the bottom half of the screen - I would like to try and work up an example of archetyping and templating the whole form, if possible. Is this for general inspection of the oral mucosa or for a particular lesion?

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst - Ocean Informatics ian.mcnicoll@oceaninformatics.com

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

2008/11/26 Olof Torgersson <oloft@chalmers.se>

13

Hi there,

I had a similar issue lately and just came up with an idea for local/custom terminology bindings - i.e. linking at codes to external terminologies not formally defined in UMLS or elsewhere.

My problem was to bind terms to latest version of SNOMED through which I access from UMLS. In the Ocean Archetype Editor when you want to add a new terminology, a list is presented (possibly taken from UMLS knowledge sources) which contains only SNOMED CT 2002 version. So I added SNOMED_CT manually via text editor:

ontology
terminologies_available = <“MST2”, “UMLS”, “SNOMED_CT”>

NOTE: editor does not like spaces in term name!

And in the term bindings section I did following:

[“SNOMED_CT”] = <
items = <
[“at0111”] = <[SNOMED_CT::C0003461]>
[“at0112”] = <[SNOMED_CT::181261002]>
[“at0113”] = <[SNOMED_CT::60184004]>

The editor does not display SNOMED_CT in the combobox but only blank line (working with enumerated text values). However you can select it and see your bindings :wink:

So custom/local terminologies can be handled this way and the implementation will be left to developers…BUT this may result in different implementations which may render interoperability in the long run…

So I suggest a sub-section within ontology section where used terminologies are declared explicitly; i.e. “umls”: 2008AA version of NLM UMLS knowledge sources. Perhaps an URI and other details can be specified (i.e. WSDL). I think it is easier for the community to agree on such a naming convention.

Custom local terminologies can be declared this way and you can create terminology names for use in term/constraint bindings.Perhaps creating a keyword (i.e. CustomTerminology) might be a good idea so that these names do not interfere with formal names.

Cheers,

-koray atalag

Ian McNicoll wrote:

14

Dear all,

The European Institute for Health Records has created a registry of coding systems.
In the (near) future they expect to be the place where coding systems and their meta-information are registered so an URL and unique identifying number will suffice.

Will this be the way to go?

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

15

Koray Atalag wrote:

Hi there,

I had a similar issue lately and just came up with an idea for
local/custom terminology bindings - i.e. linking at codes to external
terminologies not formally defined in UMLS or elsewhere.

My problem was to bind terms to latest version of SNOMED through which
I access from UMLS. In the Ocean Archetype Editor when you want to add
a new terminology, a list is presented (possibly taken from UMLS
knowledge sources) which contains only SNOMED CT 2002 version. So I
added SNOMED_CT manually via text editor:

ontology
    terminologies_available = <"MST2", "UMLS", "SNOMED_CT">

NOTE: editor does not like spaces in term name!

Hi Koray,

that's because it is illegal in the openEHR specification -
TERMINOLOGY_ID type in the Identification packge in the Support IM. Also
note that the only names that can be used are (crrently) the UMLS names
- see the spec. Also the version/revision should be indicated in ()
after, e.g.

SNOMED_CT(2008v2)::123456

or however they are identifying it. We need to determine how UMLS is
naming all of these variants / releases.

So custom/local terminologies can be handled this way and the
implementation will be left to developers....BUT this may result in
different implementations which may render interoperability in the
long run....

So I suggest a sub-section within ontology section where used
terminologies are declared explicitly; i.e. "umls": 2008AA version of
NLM UMLS knowledge sources. Perhaps an URI and other details can be
specified (i.e. WSDL). I think it is easier for the community to agree
on such a naming convention.

you can already do this -

umls(2008AA)::123456 etc

- thomas beale

16

Gerard Freriks wrote:

Dear all,

The European Institute for Health Records has created a registry of
coding systems.
In the (near) future they expect to be the place where coding systems
and their meta-information are registered so an URL and unique
identifying number will suffice.

Will this be the way to go?

I didn't know of this body. How does their registry correlate to the
UMLS list? How do they handle revisions of terminologies? How do they
handle language variants (including ones that are of earlier revisions,
or are partial)?

- thomas beale

17

Hi!

Would it be a good or bad idea to have URI:: as a valid terminology
prefix in openEHR terminology bindings, with the intention to host...

1. "local" bindings that are not foreseen to be of public general use:
URI::http://www.cs.chalmers.se/~oloft/terminologies/odont-123/local-Mucos-txtur

2. Potentially universally interesting terminologies that already have
official URIs but do not (yet?) have openEHR-defined prefix:
URI::urn:miriam:obo.go:GO%3A0045202

I guess opening up for any URIs would lead to a risk of having double
representations (URI+openEHR-prefix) for the same thing, like...
URI::urn:UMLS/CID=C0037658

...and the example URI::urn:miriam:obo.go:GO%3A0045202 is just one of
several URI-ways to point out an entry in the gene ontology..

What are the other pitfalls and/or benefits?

I guess there will probably never be only one ultimate updated
registry fitting every purpose, not from openEHR, not from EuroRec not
from anybody else.

Best regards,
Erik Sundvall
erisu@imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579

P.s. Remember that URIs include both URLs and URNs

18

There have been some discussions, but it seems like the answer to my
original question, that is, could there be other
keys than 'text and 'description' is Yes.

7.3.2, p 50 in the Archetype object model, class ARCHETYPE_TERM

items - "Hash of keys (“text”, “description” etc) and corresponding
values"

What I was asking for would be acheived by adding another key, e.g,
'name' .

A problem is of course that the GUI-editors I've seen seem to have
'text' and 'description' as the only possible keys.

Regards

Olof

25 nov 2008 kl. 23.17 skrev Olof Torgersson:

19

"comment" is another of these keys (and used in the Ocean Editor)

Regards
Sebastian

Olof Torgersson wrote:

20

Hi Erik,
As you know Ocean has been doing a lot of work making terminology and
openEHR Archetype work. Hugh Grady is the best to describe this but in
summary we are proposing the use of terminology URIs for bindings.

Bindings can reference a whole terminology, a branch of a terminology
hierarchy or a complex query which extracts specific subset of a
terminology.

To identify these there at least four identifiers; terminology ID, subset
ID, query name and query version id. There are other parameters such as
language and terminology version.

In simply cases where you just want to reference a terminology it might look
something like the following
(NOTE: these are examples to illustrate the point and are certainly not a
final proposal).
  terminology:snomed-ct?language=en-GB

or for a specific version of SNOMED
  terminology:snomed-ct(2003)?language=en-GB

For a hierarchy of a terminology it might look something like
  terminology:snomed-ct(2003)/hierarchy?rootConcept=28374832

and for a pre-specified query
  terminology:snomed-ct(2003)/query?name=AllBacteria

There are also more specific URIs for terminology queries by using subset
and query version identifiers (UIDs) mentioned above.

I believe this work is ongoing and is being proposed through IHTSDO. I
suggest we wait for that work to conclude but I thought I would let you know
that Erik's thinking is certainly the way things are being proposed.

Heath

From: openehr-technical-bounces@openehr.org [mailto:openehr-technical-
bounces@openehr.org] On Behalf Of Erik Sundvall
Sent: Monday, 1 December 2008 11:20 PM
To: For openEHR technical discussions
Subject: Re: text and description

Hi!

Would it be a good or bad idea to have URI:: as a valid terminology
prefix in openEHR terminology bindings, with the intention to host...

1. "local" bindings that are not foreseen to be of public general use:
URI::http://www.cs.chalmers.se/~oloft/terminologies/odont-123/local-Mucos-
txtur

2. Potentially universally interesting terminologies that already have
official URIs but do not (yet?) have openEHR-defined prefix:
URI::urn:miriam:obo.go:GO%3A0045202

I guess opening up for any URIs would lead to a risk of having double
representations (URI+openEHR-prefix) for the same thing, like...
URI::urn:UMLS/CID=C0037658

...and the example URI::urn:miriam:obo.go:GO%3A0045202 is just one of
several URI-ways to point out an entry in the gene ontology..

What are the other pitfalls and/or benefits?

I guess there will probably never be only one ultimate updated
registry fitting every purpose, not from openEHR, not from EuroRec not
from anybody else.

Best regards,
Erik Sundvall
erisu@imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579

P.s. Remember that URIs include both URLs and URNs

> Dear all,
> The European Institute for Health Records has created a registry of

coding

> systems.
> In the (near) future they expect to be the place where coding systems

and

> their meta-information are registered so an URL and unique identifying
> number will suffice.
> Will this be the way to go?
> Gerard
>
>
> -- <private> --
> 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

>
>
>
>
>
> So custom/local terminologies can be handled this way and the

implementation

> will be left to developers....BUT this may result in different
> implementations which may render interoperability in the long run....
>
> So I suggest a sub-section within ontology section where used

terminologies

> are declared explicitly; i.e. "umls": 2008AA version of NLM UMLS

knowledge

> sources. Perhaps an URI and other details can be specified (i.e. WSDL).

I

> think it is easier for the community to agree on such a naming

convention.

>
> Custom local terminologies can be declared this way and you can create
> terminology names for use in term/constraint bindings.Perhaps creating a
> keyword (i.e. CustomTerminology) might be a good idea so that these

names do