Suggestions re Term binding in Archetype Editor

Technical (archive)
1

Hi,

I am currently working my way slowly through the Scottish Cardiac dataset,
converting it to archetypes as proof-of-concept, using the OE editor.

Term binding (to SNOMED) will be a crucial aspect from our perspective,
especially binding local (interface) terms to SNOMED concepts.

This would be much easier within the editor if the Term bindings screen
displayed the node name as well as the Node ID, as it is easy to forget
which local term you are trying to bind by the time you have rummaged around
in Snomed for a bit!!. The "Choose Nodes" dialog might also be a little
easier if the Node parent name and Node name were included. When only the
node name is visible this can cause confusion if similar local terms are
used for different nodes e.g. "Not known".

Finally in the ADL, I think it would be very helpful to be able to include
the text of the Bound term text as well as its code. This would allow much
easier checking for errors and documenting

I have done this by enclosing the bound term text in [] for now.

e.g.
term_binding = <
    ["SNOMED-CT"] = <
      items = <
        ["at0000"] = <[SNOMED-CT::229819007 [Tobacco
use and Exposure]]>
        ["at0006"] = <[SNOMED-CT::?Non Tobacco
user]>
        ["at0009"] = <[SNOMED-CT::]>
        ["at0011"] = <[SNOMED-CT::[Ex-smoker]
8517006]>
        ["at0012"] = <[SNOMED-CT::[Current
non-smoker] 160618006]>

Regards,

Ian

2

This would be much easier within the editor if the Term bindings screen
displayed the node name as well as the Node ID, as it is easy to forget
which local term you are trying to bind by the time you have rummaged around
in Snomed for a bit!!

I would definitely second this!

3

In een bericht met de datum 15-12-2006 14:40:59 West-Europa (standaardtijd), schrijft ian@mcmi.co.uk:

Hi,

I am currently working my way slowly through the Scottish Cardiac dataset,
converting it to archetypes as proof-of-concept, using the OE editor.

Term binding (to SNOMED) will be a crucial aspect from our perspective,
especially binding local (interface) terms to SNOMED concepts.

This would be much easier within the editor if the Term bindings screen
displayed the node name as well as the Node ID, as it is easy to forget
which local term you are trying to bind by the time you have rummaged around
in Snomed for a bit!!. The “Choose Nodes” dialog might also be a little
easier if the Node parent name and Node name were included. When only the
node name is visible this can cause confusion if similar local terms are
used for different nodes e.g. “Not known”.

Finally in the ADL, I think it would be very helpful to be able to include
the text of the Bound term text as well as its code. This would allow much
easier checking for errors and documenting

I have done this by enclosing the bound term text in for now.

e.g.
term_binding = <
[“SNOMED-CT”] = <
items = <
[“at0000”] = <[SNOMED-CT::229819007 [Tobacco
use and Exposure]]>
[“at0006”] = <[SNOMED-CT::?Non Tobacco
user]>
[“at0009”] = <[SNOMED-CT::]>
[“at0011”] = <[SNOMED-CT::[Ex-smoker]
8517006]>
[“at0012”] = <[SNOMED-CT::[Current
non-smoker] 160618006]>

Regards,

Ian

I agree with Ian’s requirements, however would like to add.

In our experience some clinical materials are that detailed that not all terms can be coded with Snomed CT terms, and waiting for additions is not always possible. In such a case, or if there are requirements to work with other codes (LOINC, ICF) I work with multiple code bindings in the same archetype / template / care information models.

This would add the following 2 requirements:

  1. identify the code system itself that is used (which Ian alread presents in its listing/naming [“SNOMED-CT”]

  2. apply the ISO unique identifier for the coding system used. For snomed CT this would be: 2.16.840.1.113883.6.5

I am not fully familiar with the notations in the archetype, but it could look like this
term_binding = <
[2.16.840.1.113883.6.5:: Display name is: SNOMED-CT"] = <
items = <
[“at0000”] = <[SNOMED-CT::229819007 [Tobacco
use and Exposure]]>

where the number is the identifier and Snomed-CT the name of the terminology system(s) applied.

Similarly the ICF binding could then reside in the same archetype.

term_binding = <
[2.16.840.1.113883.6.*****:: Display name is: ICF"] = <
items = <
[“at0023”] = <[ICF::d3151 [Understanding general signs and symbols]]>

(as far as I know there is no ISO OID for ICF at this stage, or if anyone knows it and can give the source, I would be happy).

William Goossen

4

Hi William,

The ADL 1.4 ontology section already handles multiple terminologies, versioning is mentioned (against each binding) in the source for the archetype editor as being required but I cannot see anything about this in the OpenEHR reference material. The terminologies (and official Name e.g. “SNOMED-CT” are selected from a supplied list so should be unique but I agree that it might be helpful to have this cross-referenced to a code system identifier elsewhere.

Example of actual ADL below

Regards,

Ian

PS It appears we are colleagues via Derek Hoy’s Scottish Clinical Templates work.

e.g.

terminologies_available = <“SNOMED-CT”, “LNC205”>

term_definitions = <

[“en”] = <

items = <

[“at0000”] = <

description = <“Details of non-professional Patient Carer”>

text = <“Carer”>

[“at0004”] = <

description = <“*”>

text = <“Carer Name”>

term_binding = <

[“SNOMED-CT”] = <

items = <

[“at0000”] = <[SNOMED-CT::12345]>

[“LNC205”] = <

items = <

[“at0004”] = <[LNC205::121457]>

5

Hi Sam,

I appreciate the "language" difficulty here, given the ontology separation
in ADL. However, in the UK context, the ability to document bindings to
Snomed-CT with clear documentation, thereof, will be crucial to promoting
OpenEHR. The design philosophy for DV_CODED_TEXT is that the raw term is
never sent without the rubric, and I think somehow this needs to be extended
to the binding terms as it is by no means certain that access to a
terminology server will be a given in all the environments where ADL is
being used as a design / documentation language. Would it be possible to
allow the term bindings to be commented with the term name in the native
authored language(as the current dADL entries are commented with the node
name )? The current editor seems to strip out the any comments from the term
bindings. This would at least let the rubrics be captured and displayed in
any documentation.

Ian

6

Hi Ian,

Archetypes are designed to be loosely coupled with terminology so that they can be used when there are no terminology resources available.

If we have comments of the bindings, we get another problem because if the definition of the binding changes (for example a translated term is redefined in a terminology) the comment will be obsolete.

We currently have to rely on the archetypes’ local terminology to get the approximate rubrics when there are no terminology resources available.

Regards,

Mattias

2006/12/18, Ian McNicoll <ian@gpacc.co.uk>:

7

Hi Mattias,

I do appreciate these difficulties but if the definition of the binding changes the binding itself may be obsolete. I agree the comment idea is less than satisfactory, it would be better if the term binding contained the rubric as well as the term code for exactly the same reasons that the rubric must always accompany the term code in DV_CODED_TEXT.

Managing Snomed-CT is going to be a very tricky exercise. Using archetypes + bindings offers a very powerful way of managing Snomed where semantic precision is very important e.g. decision support. Having tools that will let us design and document these bindings will be a powerful way of persuading those who have yet to understand the value of the archetype approach. Having the term rubrics available is an important part of cross-checking that the correct binding has been applied, both for the original author (where terminology services might well be available) and when the archetype and bindings are reviewed by a wider clinical audience (when such services may not be available).

Regards,

Ian

8

2006/12/18, Ian McNicoll <ian@gpacc.co.uk>:

Hi Mattias,

I do appreciate these difficulties but if the definition of the binding changes the binding itself may be obsolete.

If the binding changes so much in the terminology that it may be obsolete in the archetype it would probably lead to a new term that is created in the terminology and the old one is kept… but that doesn’t matter in this discussion - just wanted to point it out.

I agree the comment idea is less than satisfactory, it would be better if the term binding contained the rubric as well as the term code for exactly the same reasons that the rubric must always accompany the term code in DV_CODED_TEXT.

I don’t know why the DV_CODED_TEXT is designed this way. I have thought about it and the only reason why this is done is probably to get a faster access to the rubric and maybe also when there are no translations for the term in a specific language in order to get a ‘default’ rubric at all times.

Maybe you’re right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license.

Regards,

Mattias

9

Ian McNicoll wrote:

Hi Sam,

I appreciate the "language" difficulty here, given the ontology separation
in ADL. However, in the UK context, the ability to document bindings to
Snomed-CT with clear documentation, thereof, will be crucial to promoting
OpenEHR. The design philosophy for DV_CODED_TEXT is that the raw term is
never sent without the rubric, and I think somehow this needs to be extended
to the binding terms as it is by no means certain that access to a
terminology server will be a given in all the environments where ADL is
being used as a design / documentation language. Would it be possible to
allow the term bindings to be commented with the term name in the native
authored language(as the current dADL entries are commented with the node
name )? The current editor seems to strip out the any comments from the term
bindings. This would at least let the rubrics be captured and displayed in
any documentation.
  

This is not an unreasonable request - it would not be particularly
difficult to implement in the specs or the tools, if we know what to
implement. We have to be careful with Snomed licensing issues however
when the terminology is snomed...

- thomas

10

Hi Ian

I appreciate the "language" difficulty here, given the ontology separation
in ADL. However, in the UK context, the ability to document bindings to
Snomed-CT with clear documentation, thereof, will be crucial to promoting
OpenEHR. The design philosophy for DV_CODED_TEXT is that the raw term is
never sent without the rubric, and I think somehow this needs to be extended
to the binding terms as it is by no means certain that access to a
terminology server will be a given in all the environments where ADL is
being used as a design / documentation language

 Would it be possible to
allow the term bindings to be commented with the term name in the native
authored language(as the current dADL entries are commented with the node
name )? The current editor seems to strip out the any comments from the term
bindings. This would at least let the rubrics be captured and displayed in
any documentation.

OK - I take your point but it needs to be language dependent - which has not be catered for in the archetype design. We can enter the text in the language which the author uses and then get the text at run time from the terminology service if it is available?

Tom, Hugh?

11

In een bericht met de datum 18-12-2006 17:28:53 West-Europa (standaardtijd), schrijft ian@gpacc.co.uk:

Hi Mattias,

I do appreciate these difficulties but if the definition of the binding changes the binding itself may be obsolete. I agree the comment idea is less than satisfactory, it would be better if the term binding contained the rubric as well as the term code for exactly the same reasons that the rubric must always accompany the term code in DV_CODED_TEXT.

Managing Snomed-CT is going to be a very tricky exercise. Using archetypes + bindings offers a very powerful way of managing Snomed where semantic precision is very important e.g. decision support. Having tools that will let us design and document these bindings will be a powerful way of persuading those who have yet to understand the value of the archetype approach. Having the term rubrics available is an important part of cross-checking that the correct binding has been applied, both for the original author (where terminology services might well be available) and when the archetype and bindings are reviewed by a wider clinical audience (when such services may not be available).
Regards,

Ian

Ian I agree fully with what you say here: there must be a strict binding possible between the information model and the terminology model. It is not only for decision support, but also for confidence that the right base materials are used to develop the archetype and for semantic interoperability. Sometimes terminologies can say the opposite of what the information model expresses. So prevention of errors in interpretation is also important.

William Goossen

12

In een bericht met de datum 18-12-2006 18:00:54 West-Europa (standaardtijd), schrijft mattias.forss@gmail.com:

Maybe you’re right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license.

Sorry, but Snomed CT cannot be considered a proprietary terminology given the formal international SDO status from January onward.

Further, most English speaking countries (Cnd, UK, US, Aus, Nw Zealand) already have a national licence allowing everyone to use it for health purposes.

William Goossen

13

In een bericht met de datum 18-12-2006 20:44:14 West-Europa (standaardtijd), schrijft Thomas.Beale@OceanInformatics.biz:

This is not an unreasonable request - it would not be particularly
difficult to implement in the specs or the tools, if we know what to
implement. We have to be careful with Snomed licensing issues however
when the terminology is snomed…

I think there is no reason to be careful if within a realm. Key is to take care where to apply and where not. My earlier comments on binding not only to one terminology but to have mapping tables with synonyms applies here too.

William

14

Williamtfgoossen@cs.com wrote:

In een bericht met de datum 18-12-2006 18:00:54 West-Europa (standaardtijd),
schrijft mattias.forss@gmail.com:

Maybe you're right, the definitions could be added as comments, but for
proprietary terminology like SNOMED CT this will mean that these kind of
archetypes can only be distributed to people that have paid the license.

Sorry, but Snomed CT cannot be considered a proprietary terminology given the
formal international SDO status from January onward.

Further, most English speaking countries (Cnd, UK, US, Aus, Nw Zealand)
already have a national licence allowing everyone to use it for health purposes.

But it is not an *open* system - and this is OpenEHR...

15

Williamtfgoossen@cs.com schreef:

In een bericht met de datum 18-12-2006 18:00:54 West-Europa
(standaardtijd), schrijft mattias.forss@gmail.com:

Maybe you're right, the definitions could be added as comments, but
for proprietary terminology like SNOMED CT this will mean that these
kind of archetypes can only be distributed to people that have paid
the license.

Sorry, but Snomed CT cannot be considered a proprietary terminology
given the formal international SDO status from January onward.

Further, most English speaking countries (Cnd, UK, US, Aus, Nw
Zealand) already have a national licence allowing everyone to use it
for health purposes.

You mean, for free? Paid by the resp. governments?

That, I did not know.

Bert

16

Dear all,

A few thoughts about this topic of Terminology Binding and Archetypes.
In essence it is the topic of “the Boundary Problem”.
Archetypes are a solution for this problem.
But in order to do so we need agreements on a few things.

We mus be extremely clear what we mean when speaking about binding terminologies in archetypes.
Are we talking about Archetypes or Templates? (design-time versus almost run-time? Generic structures versus locally agreed structures?)
Are we talking about ‘Label’ or ’ Data fields’ or ’ Archetype slots’?
Are we talking about Internal or External coding systems?
Are we talking about General External Coding Systems or specially edited sub sets of External Coding Systems, like Oceans Terminology Server and editor provide?
(Oceans product creates sub sets of a coding system to be used in a specific context. And acts at as a new refined, restricted, external coding system derived from a feeding general external coding system)

What will be rules that govern these things and prevent hazards for patients and healthcare providers?

Using the archetype editor we can provide bindings to Generic Basic Archetypes, Specialised Archetypes but also to Templates (Organising Archetypes) and Specialised Templates.
Specialisations can be made for specific clinical (sub-)domains or legal jurisdictions.
Archetypes define what maximally can be recorded about a clinical concept.
Templates define what minimally must be recorded in a specific context, as the agreement between two or more communicating partners. Most (refined) constraints will be applied in Templates.

Archetypes need some terminological bindings. Since they are general it can not be fixed fully at design time to what external terminologies they can be bound.
Primarily they will use internal codes. In particular controlled circumstances a clinical domain might adopt a specific external coding system to be used in Archetypes designed for that domain.
Most codes (internal and external) used in Archetypes will code ‘labels’ and less data fields.
When data fields are bound to a specific external coding systems there will arrise the need for a similar Archetype but bound to an other coding system. This will need an Archetype Ontology where we can create a mechanism that establishes that two archetypes express the same clinical concept but in a different way, using an other (internal or external) coding system.

In the world of Templates things are different. This is a space that is much less controlled. Local/regional/national agreements have to be made on the finest detail. Most codes will be used in data fields. A lot of local freedom will be necessary.

I have not extended the discussion of binding Archetype Slots to a coding system that is used in connection to ‘The Archetype Ontology’.

Archetypes and specialised archetypes have to be subjected to quality control in order to prevent hazards, because of errors and non-interoperability.
EuroRec (the European Institute for Health records) is executing an Europ[ean project: Q-Rec. Q-Rec will, among others, will realise an Archetype and Template Registry.
Its main purpose is to realise: Quality Labeling and Certification of EHR-systems. This will have to include Archetypes.
Eurorec will organise quality control of the archetypes and templates to be published. It might be a good idea to involve them.

Helpful in this respect is that:

  • there is an agreement between OceanInformatics and EuroRec,
  • several players from OpenEHR and CEN/tc251 EN13606 are members of the Q-Rec consortium and EuroRec,
  • persons active in EuroRec and OpenEHR take part in worldwide developments on Archetypes/templates, Semantic Interoperability, discussions on the deployment of coding systems.

Greetings,

Gerard

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

T: +31 252 544896
M: +31 653 108732

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

17

2006/12/19, Williamtfgoossen@cs.com <Williamtfgoossen@cs.com>:

In een bericht met de datum 18-12-2006 18:00:54 West-Europa (standaardtijd), schrijft mattias.forss@gmail.com:

Maybe you’re right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license.

Sorry, but Snomed CT cannot be considered a proprietary terminology given the formal international SDO status from January onward.

We’ll see about that. Read about the issues with SNOMED and LOINC here
http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_032401.html

Mattias

18

In een bericht met de datum 19-12-2006 10:52:14 West-Europa (standaardtijd), schrijft bert.verhees@rosa.nl:

You mean, for free? Paid by the resp. governments?

That, I did not know.

Bert

Yes, that is what I mean, and Denmark and the Netherlands have agreed to participate. So anyone willing to apply Snomed CT in the Netherlands and many other countries can do so I think in the 2007 area. Currently I am using it for several projects. (to develop ‘archetypes’, in HL7 v3 template disguise).

William

19

In een bericht met de datum 19-12-2006 11:28:56 West-Europa (standaardtijd), schrijft mattias.forss@gmail.com:

We’ll see about that. Read about the issues with SNOMED and LOINC here
http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_032401.html

Mattias

This is exactly what I mean: Snomed CT moving to an international SDO, and securing funding, governance and working together with WHO to sort out the issues.

So I think the propretary comments for SNomed CT no longer holds. It is eventually becoming a sister of OPEN ehr.

William

20

Williamtfgoossen@cs.com schreef:

In een bericht met de datum 19-12-2006 10:52:14 West-Europa
(standaardtijd), schrijft bert.verhees@rosa.nl:

You mean, for free? Paid by the resp. governments?

That, I did not know.

Bert

Yes, that is what I mean, and Denmark and the Netherlands have agreed
to participate. So anyone willing to apply Snomed CT in the
Netherlands and many other countries can do so I think in the 2007
area. Currently I am using it for several projects. (to develop
'archetypes', in HL7 v3 template disguise).

Stupid I did not know about this. How do they validate if you come from
Country X or Z, or a better question, how can I get access to this
materials?

Thanks, Bert