More expressivity needed

[Koray Atalag]

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

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 at openehr.org
> 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
>
>   

-- 

Koray Atalag, MD, Ph.D

Clinto

More expressivity needed

[Koray Atalag]

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 = <
> ["at"] = <"at">
>

Hope I am not pushing too far ;) 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 ve

More expressivity needed

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

More expressivity needed

[Thomas Beale]

An HTML attachment was scrubbed...
URL: 

More expressivity needed

[Koray Atalag]

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


-- 

Koray Atalag, MD, Ph.D

Clinton Bedogni Research Fellow
The University of Auckland,
Department of Computer Science,
Private Bag 92019, Auckland 1142, New Zealand

Tel: +64 (9) 373 7599 ext. 87199
Fax: +64 (9) 308 2377
Email: koray at cs.auckland.ac.nz 




__ Information from ESET NOD32 Antivirus, version of virus signature 
database 4265 (20090721) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

-- next part --
An HTML attachment was scrubbed...
URL: