More expressivity needed

Technical (archive)
1

Hi All,

I have a use case which I am having quite hard time to model. The thing is in fact very simple to express with a tabular list, spreadsheet or XML - which we do not fancy much because ADL is claimed to have much more expressive power (well in general yes)!

Here is the use-case:
A CLUSTER archetype for depicting the anatomical sites of a finding for a given organ. The clinical domain is digestive endoscopy but this applies to others I think.

So we have an organ, then list of sites and a list of “modifiers” which further specify a particular site. The simple modelling strategy to model each organ with an ELEMENT and then putting sites as values might work given that these “modifiers” can be expressed in the archetype separately and tell the application to combine these during runtime. Another option is of course using terminology service to get the proper semantics (i.e. post-coordination and subsets) - but this is not an option in my case and I must stick with local codes. I talking about 5-10 sites per organ so it does not make sense to use terminology service. Also you can say that this can further be specified by templates - true but why not putting such simple constraints at the archetype level - if we say that archetypes represent discrete clinical concepts for reuse then we should do it at archetype level.

And here is a worse version of the use-case: a given set of modifiers apply to certain - not all sites for a given organ. For example the modifiers “anterior wall”, “posterior wall” applies to fundus and body sites (of stomach)

Finally here is the nightmare version: a different set of modifiers apply to different and not all sites for a given organ. For example the modifiers “Lower third”, “Middle third” applies to “Main duct” site of pancreas and the modifiers “Left intrahepatic branches”, “Right intrahepatic branches” apply to “Liver ducts” of pancreas.

Of course a (non-elegant) modelling strategy would be to make each site as an ELEMENT and then the set of modifiers for each and every one of them as values. Then this might be problematic during GUI design and also during querying.

Here is what I suggest: add a feature in which some “attributes” can be specified for values of leaf nodes, like XML. I know this would result in dramatic changes in RM and tools (and existing implementations) but the sooner the better if you think this is useful.

Cheers,

-koray

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4265 (20090721) __________ The message was checked by ESET NOD32 Antivirus.

2

Koray Atalag wrote:

Hi All,

I have a use case which I am having quite hard time to model. The thing is in fact very simple to express with a tabular list, spreadsheet or XML - which we do not fancy much because ADL is claimed to have much more expressive power (well in general yes)!

Here is the use-case:
A CLUSTER archetype for depicting the anatomical sites of a finding for a given organ. The clinical domain is digestive endoscopy but this applies to others I think.

So we have an organ, then list of sites and a list of “modifiers” which further specify a particular site. The simple modelling strategy to model each organ with an ELEMENT and then putting sites as values might work given that these “modifiers” can be expressed in the archetype separately and tell the application to combine these during runtime. Another option is of course using terminology service to get the proper semantics (i.e. post-coordination and subsets) - but this is not an option in my case and I must stick with local codes. I talking about 5-10 sites per organ so it does not make sense to use terminology service.

using a ‘terminology service’ doesn’t depend on the number of terms in the terminology, it just depends on the need for standardised meaning , dissemination, and a capability to keep evolving the terminology. Now, it may not make sense to use an expensive big SNOMED-capable system, but logically speaking the required facility is still a terminology service, and that’s how the software should be built - even if it is a fake system just talking to a simple XML file.

Also you can say that this can further be specified by templates - true but why not putting such simple constraints at the archetype level - if we say that archetypes represent discrete clinical concepts for reuse then we should do it at archetype level.

but don’t forget, archetypes are essentially models of information use, not descriptions of the real world; the latter is the job of terminology. Archetypes are a frame-logic artefact, even for the representation, things are different - terminologies are a description logic artefact. Practically speaking, this means that archetypes are more heavily oriented to machine notions of the is-a and particularly compositional part-of relationships, while terminologies are oriented to is-a (classification) and a rich set of other relationships that occur in the real world, like part-of, uses, caused-by, has-site, symptom-of and so on.

And here is a worse version of the use-case: a given set of modifiers apply to certain - not all sites for a given organ. For example the modifiers “anterior wall”, “posterior wall” applies to fundus and body sites (of stomach)

Finally here is the nightmare version: a different set of modifiers apply to different and not all sites for a given organ. For example the modifiers “Lower third”, “Middle third” applies to “Main duct” site of pancreas and the modifiers “Left intrahepatic branches”, “Right intrahepatic branches” apply to “Liver ducts” of pancreas.

this is classic terminology / ontology stuff - we are talking here about an ontological description of the various organs, gut etc.

Of course a (non-elegant) modelling strategy would be to make each site as an ELEMENT and then the set of modifiers for each and every one of them as values. Then this might be problematic during GUI design and also during querying.

Here is what I suggest: add a feature in which some “attributes” can be specified for values of leaf nodes, like XML. I know this would result in dramatic changes in RM and tools (and existing implementations) but the sooner the better if you think this is useful.

for other reasons, this has been suggested before, and I suspect it would not be that hard to do, but so far there is not strong enough evidence of the need. I think the above problem is best solved in the terminology/ontology world!

  • thomas beale
3

Hi Tom, thanks for the comments. I see your point (and others’ who mailed me directly).

However I am not totally satisfied with the assumption that we can separate descriptions of information vs. real world in a perfectly clear way. I mean the organisation and hierarchy plus the at/ac terms given in an archetype for a clinical model still gives a lot of clues about the real world aspects. Am I still missing something here?

So now I’d like to withdraw my previous suggestion and present another:

What about having the means to be able to define a relationship type and the relationship between individual terms (with at/ac codes) given in the ontology section. I am talking about really simple relationships but also aware that this is clearly a duplication of terminology functionality; however this would greatly ease most of the typical implementations of openEHR - I mean without going into complexity and potential performance problems when working with a terminology service. I can also see relatively easy GUI generation if the relationships behaviour is straightforward.
Of course for SNOMED and possibly other decent terminologies terminology service is a must.

The thing I have in mind is like this:

ontology
term_definitions = <
[“en”] = <
items = <
[“at0001”] = <
text = <“Term A”>
description = <“Term”>

[“at0002”] = <
text = <“Term B”>
description = <“Term”>

[“at0011”] = <
text = <“Term 1”>
description = <“Related term”>

[“at0012”] = <
text = <“Term 2”>
description = <“Related term”>

relationship_definitions = <
[“is_part_of”] = <
items = <
[“at0011”] = <“at0001”>
[“at0012”] = <“at0001”>
[“at0012”] = <“at0002”>

[“another relationship”] = <
items = <
[“atXXXX”] = <“atYYYY”>

Hope I am not pushing too far :wink: Any feedback from implementers?

Cheers,

-koray

Thomas Beale wrote:

Koray Atalag wrote:

Hi All,

I have a use case which I am having quite hard time to model. The thing is in fact very simple to express with a tabular list, spreadsheet or XML - which we do not fancy much because ADL is claimed to have much more expressive power (well in general yes)!

Here is the use-case:
A CLUSTER archetype for depicting the anatomical sites of a finding for a given organ. The clinical domain is digestive endoscopy but this applies to others I think.

So we have an organ, then list of sites and a list of “modifiers” which further specify a particular site. The simple modelling strategy to model each organ with an ELEMENT and then putting sites as values might work given that these “modifiers” can be expressed in the archetype separately and tell the application to combine these during runtime. Another option is of course using terminology service to get the proper semantics (i.e. post-coordination and subsets) - but this is not an option in my case and I must stick with local codes. I talking about 5-10 sites per organ so it does not make sense to use terminology service.

using a ‘terminology service’ doesn’t depend on the number of terms in the terminology, it just depends on the need for standardised meaning , dissemination, and a capability to keep evolving the terminology. Now, it may not make sense to use an expensive big SNOMED-capable system, but logically speaking the required facility is still a terminology service, and that’s how the software should be built - even if it is a fake system just talking to a simple XML file.

Also you can say that this can further be specified by templates - true but why not putting such simple constraints at the archetype level - if we say that archetypes represent discrete clinical concepts for reuse then we should do it at archetype level.

but don’t forget, archetypes are essentially models of information use, not descriptions of the real world; the latter is the job of terminology. Archetypes are a frame-logic artefact, even for the representation, things are different - terminologies are a description logic artefact. Practically speaking, this means that archetypes are more heavily oriented to machine notions of the is-a and particularly compositional part-of relationships, while terminologies are oriented to is-a (classification) and a rich set of other relationships that occur in the real world, like part-of, uses, caused-by, has-site, symptom-of and so on.

And here is a worse version of the use-case: a given set of modifiers apply to certain - not all sites for a given organ. For example the modifiers “anterior wall”, “posterior wall” applies to fundus and body sites (of stomach)

Finally here is the nightmare version: a different set of modifiers apply to different and not all sites for a given organ. For example the modifiers “Lower third”, “Middle third” applies to “Main duct” site of pancreas and the modifiers “Left intrahepatic branches”, “Right intrahepatic branches” apply to “Liver ducts” of pancreas.

this is classic terminology / ontology stuff - we are talking here about an ontological description of the various organs, gut etc.

Of course a (non-elegant) modelling strategy would be to make each site as an ELEMENT and then the set of modifiers for each and every one of them as values. Then this might be problematic during GUI design and also during querying.

Here is what I suggest: add a feature in which some “attributes” can be specified for values of leaf nodes, like XML. I know this would result in dramatic changes in RM and tools (and existing implementations) but the sooner the better if you think this is useful.

for other reasons, this has been suggested before, and I suspect it would not be that hard to do, but so far there is not strong enough evidence of the need. I think the above problem is best solved in the terminology/ontology world!

  • thomas beale

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4283 (20090727) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


---

_______________________________________________
openEHR-technical mailing list
[openEHR-technical@openehr.org](mailto:openEHR-technical@openehr.org)
[http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical](http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical)

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4283 (20090727) __________

The message was checked by ESET NOD32 Antivirus.

[http://www.eset.com](http://www.eset.com)

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4283 (20090727) __________ The message was checked by ESET NOD32 Antivirus.

4

Hi Koray,

Koray Atalag wrote:

Hi Tom, thanks for the comments. I see your point (and others’ who mailed me directly).

However I am not totally satisfied with the assumption that we can separate descriptions of information vs. real world in a perfectly clear way. I mean the organisation and hierarchy plus the at/ac terms given in an archetype for a clinical model still gives a lot of clues about the real world aspects. Am I still missing something here?

In some kinds of medical information, the shape of the information certainly looks similar to the ontological description of the same thing - GI investigations being a good example. Nevertheless, the ontological representation contains the ‘truth’ - i.e. the statements expressing medicine’s idea of the various structures, and importantly, their classifications. The archetypes can’t do either of these things - they can’t be taken for being a true model of the gut, for example, nor can they adequately express classificatory relationships. So the ontology will always be richer in these areas. The archetypes on the other hand will be richer in observational detail - size, shape, character of lumps, narrowings, pockets, lesions, etc.

So now I’d like to withdraw my previous suggestion and present another:

What about having the means to be able to define a relationship type and the relationship between individual terms (with at/ac codes) given in the ontology section. I am talking about really simple relationships but also aware that this is clearly a duplication of terminology functionality; however this would greatly ease most of the typical implementations of openEHR - I mean without going into complexity and potential performance problems when working with a terminology service.

I don’t think we should be saying this. If terminology is ‘difficult’ we need to make it easier. Just because of some technical difficulties (of which I am not aware) we should not break the philosophical basis of a modelling paradigm. As soon as we add some facilities to partially model terminology, people will step into that world in archetypes, and ask for more; then we will be in trouble, because we will be replicating what is in Snomed, ICDx, ICPC and all the rest.

I can also see relatively easy GUI generation if the relationships behaviour is straightforward.
Of course for SNOMED and possibly other decent terminologies terminology service is a must.

not just Snomed; various countries have numerous very small terminologies, one could really only call them vocabularies. These benefit hugely from being available in a terminology service, because it provides:

  • an authoratative source

  • a capability for update

  • a query facility

  • some services will provide a capability for subsetting
    I would recommend people look at the CTS2 specification when published. I think in openEHR we should not shy away from ‘proper’ solutions - there is no lasting value in over-simplified approaches.

  • thomas beale

5

Hi Tom, now I am very clear on how openEHR looks at this whole thing and agree :slight_smile:

Having said that, I’d be very keen to hear about especially GUI design and runtime data entry and validation aspects from implementers. In this case the thing is not simply parsing the archetype structure and terms and building functionality, but now an openEHR based application will need some means to access the terminology, get the terms, get relationships and possibly do some processing. I will be looking forward to seeing the CTS2 specification.

In a similar vein I remember the discussions about semantic references or links at openEHR previously. I don’t remember how this ended but I was reminded recently that in fact EN13606 has Semantic Links defined in its reference model which can be used within and across archetypes. This looks to me to cause serious divergence between openEHR and CEN (and possibly ISO).

At any rate I think it would be quite useful to have a simple tool with which simple terminology content can be created and persisted in XML.

Many thanks and cheers,

-koray

Thomas Beale wrote:

Hi Koray,

Koray Atalag wrote:

Hi Tom, thanks for the comments. I see your point (and others’ who mailed me directly).

However I am not totally satisfied with the assumption that we can separate descriptions of information vs. real world in a perfectly clear way. I mean the organisation and hierarchy plus the at/ac terms given in an archetype for a clinical model still gives a lot of clues about the real world aspects. Am I still missing something here?

In some kinds of medical information, the shape of the information certainly looks similar to the ontological description of the same thing - GI investigations being a good example. Nevertheless, the ontological representation contains the ‘truth’ - i.e. the statements expressing medicine’s idea of the various structures, and importantly, their classifications. The archetypes can’t do either of these things - they can’t be taken for being a true model of the gut, for example, nor can they adequately express classificatory relationships. So the ontology will always be richer in these areas. The archetypes on the other hand will be richer in observational detail - size, shape, character of lumps, narrowings, pockets, lesions, etc.

So now I’d like to withdraw my previous suggestion and present another:

What about having the means to be able to define a relationship type and the relationship between individual terms (with at/ac codes) given in the ontology section. I am talking about really simple relationships but also aware that this is clearly a duplication of terminology functionality; however this would greatly ease most of the typical implementations of openEHR - I mean without going into complexity and potential performance problems when working with a terminology service.

I don’t think we should be saying this. If terminology is ‘difficult’ we need to make it easier. Just because of some technical difficulties (of which I am not aware) we should not break the philosophical basis of a modelling paradigm. As soon as we add some facilities to partially model terminology, people will step into that world in archetypes, and ask for more; then we will be in trouble, because we will be replicating what is in Snomed, ICDx, ICPC and all the rest.

I can also see relatively easy GUI generation if the relationships behaviour is straightforward.
Of course for SNOMED and possibly other decent terminologies terminology service is a must.

not just Snomed; various countries have numerous very small terminologies, one could really only call them vocabularies. These benefit hugely from being available in a terminology service, because it provides:

  • an authoratative source

  • a capability for update

  • a query facility

  • some services will provide a capability for subsetting
    I would recommend people look at the CTS2 specification when published. I think in openEHR we should not shy away from ‘proper’ solutions - there is no lasting value in over-simplified approaches.

  • thomas beale

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4286 (20090728) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


---

_______________________________________________
openEHR-technical mailing list
[openEHR-technical@openehr.org](mailto:openEHR-technical@openehr.org)
[http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical](http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical)

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4286 (20090728) __________

The message was checked by ESET NOD32 Antivirus.

[http://www.eset.com](http://www.eset.com)

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4286 (20090728) __________ The message was checked by ESET NOD32 Antivirus.