Re: SNOMEDCT - correct representation

[Daniel Karlsson]

See this page:
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard
Please consider the language used when posting.
/Daniel

On May 3, 2017 13:03, Bert Verhees  wrote:
On 03-05-17 12:53, Thomas Beale wrote:
On 03/05/2017 11:40, Bert Verhees wrote:
On 03-05-17 12:36, Thomas Beale wrote:

The only missing part, now that I look at the SNOMED Compositional 
Grammar and Expression 
Constraint Language specs, 
is how to create a URI (which is the type of a term binding in 
ADL2)
 from a post-coordinated expression or constraint expression. This should be 
trivial, but I don't see where SNOMED has specified it.

True, I was looking for that also, a few days ago. I don't have time to read 
much now, but there is a document on the SNOMED site on URI's, maybe it is in 
there?
I can take a look later or look in my documentation, I have course materials. I 
come back to this tomorrow if not someone else already has.

The URI spec is 
here, 
but it doesn't address URIs for expressions either.

(All the SNOMED language specs appear to be 
here
 these days - nice and convenient, and also nicely published. We probably 
should go back to linking to them somewhere on the openEHR site).

I checked my course materials from last year, lucky I found it quickly, there 
is not any mentioning of URI's for expressions, so I guess it does not yet 
exist.

Stupid.

Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMEDCT - correct representation

[Daniel Karlsson]

Hi All,

please use this link to refer to the SNOMED CT URI Standard: 
https://confluence.ihtsdotools.org/display/DOCURI

This page contains more info about SNOMED CT languages:
https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Languages+Project+Group

Thanks,
Daniel
On ons, 2017-04-26 at 14:00 +0100, Thomas Beale wrote:


In the new world of URIs representing SNOMED codes, this "SNOMED-CT" value for 
the terminology_id is understood as an openEHR-local (and maybe more widely 
agreed) namespace alias for the SNOMED CT namespace whose URI is 
http://snomed.info/sct (see 
http://doc.ihtsdo.org/download/doc_UriStandard_Current-en-US_INT_20140527.pdf).

Practically speaking this means that if other variants exist, e.g. 'snomed_ct', 
'SNOMED_CT' and so on, they can all be defined as aliases for SNOMED CT, in 
different contexts such as archetype tools, AQL queries and so on.

BTW, the ARchetype editor should generate URIs of this form for terminologies 
(from the ADL2 converted form of the CKM BP archetype):

term_bindings = <
["SNOMED-CT"] = <
["id1"] = 

["id5"] = 

["id6"] = 

["id14"] = 

>
["openehr"] = <
["at1055"] = 
["at1056"] = 
["at1057"] = 
>
>

- thomas

On 25/04/2017 07:03, Ian McNicoll wrote:
SNOMED-CT is the official designator, based on the archetype editor terminology 
list.
On Tue, 25 Apr 2017 at 06:36, Pablo Pazos 
> wrote:
Congratulations about the new adoption!

The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our specs we 
are using SNOMED-CT as the name (it should be corrected to the name preferred 
by the IHTSDO). On an event they explicitly asked to avoid the SNOMED-CT with 
the hyphen when referencing the standard.

As for the term id, I've seen [snomed-ct::35917007 on the specs, or SNOMED-CT 
on sample archetypes: 
https://github.com/openEHR/specifications-ITS/search?utf8=%E2%9C%93=snomed=

Tested on the Ocean's archetype editor and they use:

constraint_bindings = <
["SNOMED-CT"] = <
items = <
["ac0001"] = 
>
>
>



On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss > 
wrote:
Norway just became a SNOMED country.
One simple question – what is the correct terminologyId to use for SNOMED-CT.

Currently we use ‘SNOMEDCT’ like below. Is this correct?

 
Høyre øye

  
SNOMEDCT
  
  18944008

  

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10


___

openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org




--
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Ian McNicoll



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
[http://www.openehr.org/files/about/logoweb.png]
Thomas Beale
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR and terminology servers

[Daniel Karlsson]

Hi Pablo,

unfortunately that didn't happen, at least until now.

Technically, the system used a relational database to persist SNOMED CT 
and expression versions over time and an OWL ontology of SNOMED CT and 
expressions  and the two were kept in sync. Expansion was just a query 
of the the transitive closure table.


/Daniel


On 2016-12-04 01:53, Pablo Pazos wrote:

Hi Daniel,

Did your team publish any articles about the demonstration? I'm 
interested in the technical aspects of querying expansion of results.


Thanks!

On Fri, Dec 2, 2016 at 10:01 AM, Daniel Karlsson 
<daniel.karls...@liu.se <mailto:daniel.karls...@liu.se>> wrote:


Hi All,

so I'll start:

At Linköping University we did a demonstrator in 2012 using a
homebrew REST interface to an expression repository based on the
SNOMED CT query language at the time. The demonstrator showed
querying over EHR content including both AQL and the SNOMED CT
query language. The terminology server per default did expansion
of results of the SNOMED CT queries, i.e. it returned a set of
SCTID:s+expression id:s. The aim of this experiment was to show
that some very complex quality indicators could be expressed as
queries on a structured health record.

/Daniel


On 2016-12-02 11:33, Grahame Grieve wrote:

hi Daniel

I'll listen to this discussion with interest. I expect that the
answer will be: same functional needs as already covered by FHIR
terminology services, but there's some additional information
features that are needed to enable seamless integration.

Grahame


On Fri, Dec 2, 2016 at 7:50 PM, Daniel Karlsson
<daniel.karls...@liu.se <mailto:daniel.karls...@liu.se>> wrote:

Dear All,

while thinking about terminology server requirements for
openEHR systems
I would like to ask all openEHR implementers about experiences of
different solutions. Are there any experiences of using
openEHR systems
with e.g. the FHIR terminology services, CTS2, Ocean TQL,
homebrew, etc?
What are the use cases when the terminology servers are used
(e.g.
design time, data entry, querying, etc.)? What are the
"terminological
queries" that are used/needed (e.g. subsumption testing, subset
membership, subset expansion, etc.)?

Thanks,
    Daniel

    --

Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109 <tel:%2B46%20708350109>, Skype: imt_danka,
Hangout: daniel.e.karls...@gmail.com
<mailto:daniel.e.karls...@gmail.com>


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>




-- 
-

http://www.healthintersections.com.au
<http://www.healthintersections.com.au> /
grah...@healthintersections.com.au
<mailto:grah...@healthintersections.com.au> / +61 411 867 065
<tel:+61%20411%20867%20065>


-- 
Daniel Karlsson, PhD, sr lecturer

Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph.+46 708350109 <tel:+46%2070%20835%2001%2009>, Skype: imt_danka, 
Hangout:daniel.e.karls...@gmail.com <mailto:daniel.e.karls...@gmail.com>


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>




--
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com <http://www.cabolabs.com/>
pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR and terminology servers

[Daniel Karlsson]

Hi All,

so I'll start:

At Link?ping University we did a demonstrator in 2012 using a homebrew REST 
interface to an expression repository based on the SNOMED CT query language at 
the time. The demonstrator showed querying over EHR content including both AQL 
and the SNOMED CT query language. The terminology server per default did 
expansion of results of the SNOMED CT queries, i.e. it returned a set of 
SCTID:s+expression id:s. The aim of this experiment was to show that some very 
complex quality indicators could be expressed as queries on a structured health 
record.

/Daniel

On 2016-12-02 11:33, Grahame Grieve wrote:
hi Daniel

I'll listen to this discussion with interest. I expect that the answer will be: 
same functional needs as already covered by FHIR terminology services, but 
there's some additional information features that are needed to enable seamless 
integration.

Grahame


On Fri, Dec 2, 2016 at 7:50 PM, Daniel Karlsson 
<daniel.karls...@liu.se<mailto:daniel.karls...@liu.se>> wrote:
Dear All,

while thinking about terminology server requirements for openEHR systems
I would like to ask all openEHR implementers about experiences of
different solutions. Are there any experiences of using openEHR systems
with e.g. the FHIR terminology services, CTS2, Ocean TQL, homebrew, etc?
What are the use cases when the terminology servers are used (e.g.
design time, data entry, querying, etc.)? What are the "terminological
queries" that are used/needed (e.g. subsumption testing, subset
membership, subset expansion, etc.)?

Thanks,
Daniel

--

Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Link?ping university
SE-58185 Link?ping
Sweden
Ph. +46 708350109<tel:%2B46%20708350109>, Skype: imt_danka, Hangout: 
daniel.e.karls...@gmail.com<mailto:daniel.e.karls...@gmail.com>


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
-
http://www.healthintersections.com.au / 
grah...@healthintersections.com.au<mailto:grah...@healthintersections.com.au> / 
+61 411 867 065


--
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Link?ping university
SE-58185 Link?ping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: 
daniel.e.karls...@gmail.com<mailto:daniel.e.karls...@gmail.com>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR and terminology servers

[Daniel Karlsson]

Dear All,

while thinking about terminology server requirements for openEHR systems
I would like to ask all openEHR implementers about experiences of
different solutions. Are there any experiences of using openEHR systems
with e.g. the FHIR terminology services, CTS2, Ocean TQL, homebrew, etc?
What are the use cases when the terminology servers are used (e.g.
design time, data entry, querying, etc.)? What are the "terminological
queries" that are used/needed (e.g. subsumption testing, subset
membership, subset expansion, etc.)?

Thanks,
Daniel

-- 

Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: More generic reference model

[Daniel Karlsson]

Bert,

if I understand your issue correctly, I believe that some sort of "code 
index" is needed in openEHR persistence implementations. This "code 
index" would link all codes used with the (full) path to the node where 
the code is used. There are several considerations to be made when 
implementing such an index, including making certain that the 
information context is clear (e.g. a code in an exclusion archetype vs. 
one in the problem archetype), which other pieces are needed to build 
the index, like archetypes and templates used in the path, which codes 
to index (archetype- and template-bound codes as well as coded values). 
I assume the brilliant people on the openEHR lists knows more about such 
things than I do :)


Cheers,
Daniel


On 2016-09-02 09:41, Bert Verhees wrote:

Sorry, this was a mix-up of two concerns

We are stating in an archetype that we are doing an observation on 
blood pressure, and we state that again using SNOMED and LOINC. LOINC 
to define the observation and SNOMED to support the 
observation-result-definition.



One is the redundancy. The problem with redundancy is that it can be 
error prone when there is a slight difference in meaning of the 
content and archetype ID. When the reference model suggest that the 
archetype clincial idea is a part of group of clinical idea's (f.e. 
Observations), and a internal coding suggest something which has 
difficulties fitting exact in the OpenEHR entry-types and suggest 
something slightly different. Which one is then to follow? Better, I 
think, would be to assign a  generic structure, so there can be no 
misunderstanding and let a terminology-coding decide what the 
archetype is about. Notice that I do not specify the term 
"terminology-coding", so it does not have to be SNOMED if there are 
strong reasons to not use it. (f.e. a non-member-country)


Except from redundancy, there may also be a problem of not using the 
potential of SNOMED.



This one is a bit harder to explain, but the problem is that when you 
don't know the path to a terminology code, because it differs in 
different archetypes, you cannot query for that code.
The query consists of the archetype ID and the path inside the 
archetype. So there are two problem parts.


In the FROM part: The archetype ID is a representation of the clinical 
idea which is represented in the archetype. I understand it is 
possible to use regular expressions in a query in the FROM part, and 
in this way have a selection from more then one archetypes to query in 
one time. But regular expressions operate on series of characters, not 
on clinical hierarchies. So it is not possible to query in archetype 
ID's on hierarchy of clinical ideas.


In the WHERE part: When the path to a terminology coding is not known, 
and this is the case when there are more entry-types, and even in a 
generic entry-type this can be a problem. So there should be a fixed 
location which can be reached by AQL where coding occurs, so the 
potential of SNOMED in relations and hierarchies can be guaranteed 
successfully used in AQL queries. As it is now, we cannot be sure that 
we miss something in a query which is in a obscure archetype. This is 
especially the case when the number of used archetypes outreaches the 
human comprehension limits, for example the idea when more EPD's are 
queried in one time, or are compiled in regional cooperation of 
healthcare facilities or hospital mergers.


---
So, that are my concerns, I hope I explained them well, I see that 
yesterday I made a few jumps in my thoughts which where hard to follow 
for others. Excuse me for that


Best regards
Bert Verhees


On 01-09-16 11:20, Bert Verhees wrote:

Thank you for your reply, Diego.


___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org 



--
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com

<>___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: UCUM code in body temperature archetype

[Daniel Karlsson]

So, right now the DV_QUANTITY.units is a String, perhaps it should be 
DV_CODED_TEXT?


/Daniel

On 2016-05-18 10:25, Bakke, Silje Ljosland wrote:
This imposes a larger implementation burden on the systems who will 
have to be able to read UCUM codes and show the corresponding symbol 
instead of the code, which in many cases is not readable to clinicians.


--
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com

<>___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

UCUM code in body temperature archetype

[Daniel Karlsson]

Dear All,

it seems the UCUM code for the temperature units in the Body temperature 
archetype is wrong. It uses the UCUM print symbol, e.g. "°C", rather 
than the UCUM code "Cel".


http://www.openehr.org/ckm/#showArchetype_1013.1.49

Regards,
Daniel

--
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMED

[Daniel Karlsson]

Hi Bert,

comments below!

On 2016-04-29 17:04, Bert Verhees wrote:
Hi Daniel, thanks, I posted the idea also to some Dutch groups, one 
argument was that there is no workflow in SNOMED.


It is not a perfect solution.

Therefore I am glad you mention the low hanging fruit, and maybe it is 
more then "some", maybe it is  a lot.


So let us concentrate on that, and see where we would be able to come.

Yes, let's see. I'm still a skeptic though ;)


* the use cases are not the same - ontologies represent universal 
truths about the world, archetypes represent record keeping requirements


I understand your argument, but is that universal true? aren't there 
any structures usable for recording in SNOMED. I am not a clinician. 
So, I always have the wrong examples.


I checked "fever" in the SNOMED browser.

There are many subtypes, Malarial fever, Hay fever, Q fever, etc
Yes, the terminology may be used to populate value sets for coded 
elements. SNOMED CT will additionally tell you that fever has some 
connection to body temperature. This is needed in SNOMED CT to formally 
define the SNOMED CT concepts, but won't help anyone building an 
archetype for patients with fever (perhaps not the best of examples). 
It's universally true definitional knowledge, and thus typically not 
that exciting to record.
But there is also the primitive attribute Body Temperature (observable 
entity) which can contain to a value. So that can be used for 
recording, can't it?
The way it would be used would be to bind it to an archetype node. 
Still, while SNOMED CT can well be used for terminology binding, using 
the structure of SNOMED CT, the SNOMED CT concept model, is a different 
matter. The SNOMED CT concept model might tell you that a Finding has a 
Finding site which is a kind of Anatomical or acquired body structure. 
This might have some relation to the Body site in the 
openEHR-EHR-EVALUATION.problem_diagnosis.v1 archetype. Of the 14 
attributes of that archetype though only a few has any such 
correspondence to the SNOMED CT concept model. Of the 15 allowed 
attributes for Findings only a few corresponds to archetype elements. 
Then, there might be somethings to be done (the low-hanging fruit), like 
if the Body site (not Structured body site!) also has a SNOMED CT code 
you might bridge between a SNOMED CT concept with a Finding site and an 
archetype instance with a Body site. However, I assume the archetype 
Body site would often be used when there isn't a simple site which can 
be given a single code.


* ontologies and archetypes have different "reasoning" requirements 
and thus different representation languages, algorithms etc. (the 
ontology-information model separation is a divide-and-conquer approach)


There are a lot of similarities, supertypes, subtypes, attributes, I 
haven't found until now a structure which does not fit in an archetype.

I think, I must be missing something.
True, but also dissimilarities: open vs. closed world, unique name 
assumption vs. not, untyped vs. typed, different sets of operators, etc.


* for ontologies to compute meaningfully, a larger degree of 
consistency is needed, archetypes may be (and are being) developed 
and used with such a need


I am not sure I understand what you want to express here. Can you 
explain it, maybe with an example.
Sure, I've been working on creating some templates for an assisted 
living/IoT kind-of project and the archetypes I used have a few 
different patterns for representing measurement values, e.g. simple ones 
like openEHR-EHR-OBSERVATION.body_temperature.v1 where the kind of 
observation is in the element name and more complex ones like 
openEHR-EHR-OBSERVATION.lab_test.v1 where you have to specify the kind 
of observation with a specific element (at0005::Test name). For 
archetypes this is generally no problem, if you know which archetype is 
used, you know how to query. This "lack of consistency" also allows the 
archetypes to be tailored to specific needs. For an ontology, if you 
were to have different patterns you would end up with different 
hierarchies and you would get false negative subsumption test results.


Cheers,
Daniel


Thanks
Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 



--
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com

<>___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SNOMED

[Daniel Karlsson]

g with e.g. some built in post-coordination-generating
logic combined with some extended (AQL?)querying-capabilities in
openEHR storage systems could help openEHR-based systems jump
ahead of a lot of the EHR competitors regarding efficient Snomed
CT use...

It is often good to look at Snomed CT when designing archetypes.
Especially the high quality parts of Snomed CT (there is constant
maintenance and cleanup going on). I believe this is happening
more already when designing archetypes today.

Regarding licensing I believe there has been a discussion going
on between IHTSDO and the openEHR foundation for a long
time, perhaps the management board has an update?

I believe we might need to add a function to
repositories/CKMs that removes Snomed bindings/codes from
archetypes if downloaded by non-licensed users. (A lot of the
structure/content itself is based on (non protected) general
medical knowledge and I believe IHTSDO concludes it can be partly
reused without license, thus not stopping global use
of Snomed-inspired archetypes.)

Others will surely add more to the discussion.

//Erik Sundvall

Sent from mobile...

fredag 29 april 2016 skrev Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>>:

Part two is of course, generating templates, and we almost
have the GUI's in place.

It is the enormous collection of medical datastructures which
can be the source of many generated EPD-software.

Bert

On 29-04-16 08:50, Bert Verhees wrote:

Hi,

I got an idea when reading the nice story from Heather on
LinkedIn. In fact it is hers idea, but in a opposing way.

https://www.linkedin.com/pulse/journey-interoperability-part-i-heather-leslie


https://www.linkedin.com/pulse/journey-interoperability-part-ii-heather-leslie


I wonder in how far it is feasible and useful to create
archetypes from SNOMED concepts, it would be possible to
generate them, with attributes and so on.
In a few hours time, one would have a complete forest
with archetypes, including ontology in more languages.
Maybe some smart handling, filtering, combining can
create a better collection, also looking at the paths, so
that there are similar paths for similar situations, to
keep the number of different datapoints low, which can
help creating a faster key-value storage.

I don't know how it is about copyright, with members, and
licensing, that should be looked at.

The argument that SNOMED is fragmented should not count,
I think (however without having an expertise on this),
because, when working with handwritten archetypes will
always be incomplete and fragmented.

Bert



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



-- 
Sent from mobile.



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Health informatics
Linköping university
SE-58185 Linköping
Sweden
Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com

<>___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

radical idea - where term value sets should be defined in archetypes.

[Daniel Karlsson]

Thomas and All,

[Sent to CIMI-list as well... Sorry for cross-posting]

From what I can see the
difference, apart from syntax, from the current AOM is that value sets
are named objects by themselves. This would actually solve the problem
of
implementing the proposed CIMI terminology binding model in archetypes:
(using openEHR terminology biniding terminology) OBJECT bindings would
be term bindings of value sets, VALUE SET bindings would be assignment
of at-codes to value sets. Then it's just figuring out how those kinds
of bindings are to be used and explained to archetype users...

I see a number of alternative syntaxes for assigning at-codes to value
sets though, e.g.

[vs1001] = 
   text = Blood pressure measuring position
   description = Position of patient at time of measuring blood
pressure.
   content = at1001 at1002 ...
 

or

[at1001] = 
   text = Standing
   description = Standing at the time of blood pressure measurement.
   valueset = vs1001 vs1009...
 

This would probably enhance readability, as a archetype reader would
have to look in two places and not three places to determine the
contents of a value set.

Cheers,
Daniel

On Tue, 2014-01-14 at 10:04 +, Thomas Beale wrote:
 
 I have created a wiki page to describe a possibly radical idea about
 how we define value sets (like body position etc) in archetypes. 
 
 all feedback welcome.
 
 - thomas
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

openEHR-technical Digest, Vol 18, Issue 38

[Daniel Karlsson]

 the meaning of the 
  intermediate classes.
  The logic of the tools and the validation checks of archetypes are built 
  based on those interpretations. I agree with Bert in one thing: tools 
  shouldn't change things without notifications, but in this case we face a 
  methodological difference, not just a configuration one, and that's why it 
  is not easy to be solved.
  David
  -- next part --
  An HTML attachment was scrubbed...
  URL: 
  http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment-0001.html
  --
  Subject: Digest Footer
  ___
  openEHR-technical mailing list
  openEHR-technical at lists.openehr.org
  http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
  --
  End of openEHR-technical Digest, Vol 18, Issue 37
  *
  
  ___
  openEHR-technical mailing list
  openEHR-technical at lists.openehr.org
  http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
  
  
  
  
  
  --
  
  Subject: Digest Footer
  
  ___
  openEHR-technical mailing list
  openEHR-technical at lists.openehr.org
  http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
  
  --
  
  End of openEHR-technical Digest, Vol 18, Issue 38
  *
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- 
Daniel Karlsson, PhD, sr lecturer
Department of Biomedical Engineering/Medical Informatics
Link?ping University
SE-58185 Link?ping
Ph. +4613286762/+46708350109, Skype: imt_danka, G+:
daniel.e.karlsson at gmail.com

openEHR-technical Digest, Vol 18, Issue 38

[Daniel Karlsson]

Gerard, Everyone,

could you please *NOT* reuse existing terms like open world and
closed world with an already agreed specific meaning in a well-defined
context for your own purposes!

On the topic of descriptive vs. prescriptive I believe that that is an
additional dimension in this discussion. I still want to have an answer
to the question of what to do with archetype nodes for which there are
no existing terminology correspondence. Should we ban those archetype
nodes or should we (over)inflate terminologies with imprecise content or
should we just accept that archetypes and terminology are different
artefact beasts with different properties and that we have to thread
carefully balancing terminology binding possibilities and specific use
case requirements?

/Daniel

On Thu, 2013-08-29 at 10:53 +0200, Gerard Freriks wrote:
 yes, I agree.
 
 
 And it is the same as communication in a 'closed world' or 'open
 world' situation.
 
 
 Gerard Freriks
 +31 620347088
 gfrer at luna.nl
 
 On 29 aug. 2013, at 09:50, gjb gjb at crs4.it wrote:
 
  Re: Ontology  archetype codes
  
  aren't we, here, in the realms of Descriptive v. Prescriptive
  Grammar?
  
  http://grammar.about.com/od/basicsentencegrammar/f/descpresgrammar.htm
  
  *Descriptive* obliges you to change whenever the language seems to.
  
  *Prescriptive* obliges you to try to hold the language static.
  
  The hard bit is gauging the utility of responding to any given
  change.
  
  
  Gavin Brelstaff
  CRS4 in
  Sardinia
  
  
  ___
  openEHR-technical mailing list
  openEHR-technical at lists.openehr.org
  http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

TDS (and TDD) implementations?

[Daniel Karlsson]

Hi Ian,

On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote:
 Hi Erik,
 
 
 The Ocean TDD-canonical transform is available at
 
 
 http://openehr.codeplex.com/SourceControl/latest#176376
 
 
 
 look for TDD_to_openEHR.xsl
 
 
 As far as I know a generic reverse transform is not possible.

How could that be? Is there something in the TDD format that is not in
the RM format? The intuition tells me that it should be easier going
from the rich RM format to the TDD format than in the opposite
direction. What are the specific issues that make a reverse
transformation problematic? Could anything be changed to make the
transformation possible?

/Daniel
 
 
 There are at least 3 or 4 companies using TDD as part of their CDR
 offering. 
 
 
 It would be good to make this part of the managed standard and public
 spec .
 
 
 Ian 
 
 
 
 On 30 May 2013 10:21, Erik Sundvall erik.sundvall at liu.se wrote:
 Hi!
 
 
 Which projects and products out there support TDS (Template
 Data Schema)? And do they support conversion of TDDs (Template
 Data Documents) to standard canonical openEHR RM instances
 (in e.g. XML)? Is there any available XSLT, webservice or
 other thing that can convert bidirectionally between TDD and
 openEHR RM-based instances?
 
 
 What about a TDS specification? Is there any published or
  work-in-progress document? If not is there any entity, group
 or person that could/should be sponsored or bribed to produce
 such a thing? :-) It seems to be on the
 roadmap http://www.openehr.org/programs/specification/roadmap and 
 described there anyway...
 
 
 I think TDS is an essential component in the toolbox in
 practical openEHR integration projects but without a public
 spec, it will be harder to take seriously and hard to make
 compatible implementations.
 
 
 (ExampleTDS-info for people not familiar with the
 approach: 
 http://www.mz.gov.si/fileadmin/mz.gov.si/pageuploads/eZdravje/Novice/gradiva_predstavitve_dogodkov/Open_EHR/7_integration.pdf)
 
 
 Best regards,
 Erik Sundvall 
 Tel: +46-72-524 54 55
 LiO: erik.sundvall at lio.se 
 http://www.lio.se/Verksamheter/IT-centrum/
 LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 
 
 
 
 -- 
 Dr Ian McNicoll
 office +44 (0)1536 414 994
 fax +44 (0)1536 516317
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com
 
 Clinical Modelling Consultant, Ocean Informatics, UK
 Director openEHR Foundation  www.openehr.org/knowledge
 Honorary Senior Research Associate, CHIME, UCL
 SCIMP Working Group, NHS Scotland
 BCS Primary Health Care  www.phcsg.org
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

TDS (and TDD) implementations?

[Daniel Karlsson]

On Fri, 2013-06-14 at 09:56 +0200, Gerard Freriks wrote:
 Hi,
 
 
 While we are at it.
 
 
 -1-
 Why do we need a TDD?
 Isn't a Template just a Composition archetype with Sections archetypes
 and ENTRY archetypes and Cluster archetypes and Element archetypes
 plus data types.
With ADL 1.5, yes I believe.

 In addition as many possible degrees of freedom need to be constrained
 so as to reflect the agreement between the two exchanging actors.
 In all aspects they rare nothing but an archetype in my part of the
 world.
Ok

 The peculiar thing about templates is that they are for prime time
 actual use/deployment.
What's peculiar about that?

 
 -2-
 Transformations:
 The Template (archetype) has node names changed in places (and
 therefor their meaning).
No, these are (should be) just two alternative serializations of the
same meaning. However, what constitutes the meaning of an archetype is
not a trivial question.
 They are more complex in places (because new branches) have been
 added, less complex in places (because branches are not used), more
 constrained in places than the pure parent archetype.
Here I must confess I don't understand your use of the word complex.
E.g. if there in an openEHR model is two specific named events in an
observation which are expanded in the TDD (isn't it??) does this
increase or decrease complexity?
 
 
 To write generic transformations is not trivial, I expect.
 If possible at all.
I do not agree. I believe this is what every implementer necessarily has
to do, to provide a two-way transformation between a canonical form and
any serialization and/or persistence form with a different set of
requirements (query performance, OLTP vs. OLAP, space requirements,
legacy systems integration, etc. etc. etc.). Not trivial but done on a
regular basis.


Cheers,
Daniel

 Gerard Freriks
 +31 620347088
 gfrer at luna.nl
 
 On 14 jun. 2013, at 09:41, Daniel Karlsson Daniel.Karlsson at liu.se
 wrote:
 
  Hi Ian,
  
  On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote:
   Hi Erik,
   
   
   The Ocean TDD-canonical transform is available at
   
   
   http://openehr.codeplex.com/SourceControl/latest#176376
   
   
   
   look for TDD_to_openEHR.xsl
   
   
   As far as I know a generic reverse transform is not possible.
  
  How could that be? Is there something in the TDD format that is not
  in
  the RM format? The intuition tells me that it should be easier going
  from the rich RM format to the TDD format than in the opposite
  direction. What are the specific issues that make a reverse
  transformation problematic? Could anything be changed to make the
  transformation possible?
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

TDS (and TDD) implementations?

[Daniel Karlsson]

Hi Gerard,

see below...

On Fri, 2013-06-14 at 11:54 +0200, Gerard Freriks wrote:
 
 See below
 Gerard Freriks
 +31 620347088
 gfrer at luna.nl
 
 On 14 jun. 2013, at 11:09, Daniel Karlsson daniel.karlsson at liu.se
 wrote:
 
  On Fri, 2013-06-14 at 09:56 +0200, Gerard Freriks wrote:
   Hi,
   
   
   While we are at it.
   
   
   -1-
   Why do we need a TDD?
   Isn't a Template just a Composition archetype with Sections
   archetypes
   and ENTRY archetypes and Cluster archetypes and Element archetypes
   plus data types.
  With ADL 1.5, yes I believe.
 
 
 We, EN13606 Association, use the ADL1.4 spec in our tool: LinkEHR.
 This is sufficient for our and CIMI purposes, we believe.
Ok
 
 
 
  
   In addition as many possible degrees of freedom need to be
   constrained
   so as to reflect the agreement between the two exchanging actors.
   In all aspects they rare nothing but an archetype in my part of
   the
   world.
  Ok
  
   The peculiar thing about templates is that they are for prime time
   actual use/deployment.
  What's peculiar about that?
 
 
 'Normal' archetypes can be produced just to produce other archetypes
 at design time.
 
 
 Templates are for specific use in a specific context and moment in
 time when actors define a screen or the content of an exchange.
 Of course Templates can be designed as templates to be used in local
 contexts.
 
 
 Archetypes can not be used without the Composition because a lot of
 the audit info and other info needed for versioning is defined at the
 Composition level.
 The meta-data about the pay load is defined in the EHR-Extract.
 Templates are mostly EHR-EXtracts with Compositions inside.
 
  
   
   -2-
   Transformations:
   The Template (archetype) has node names changed in places (and
   therefor their meaning).
  No, these are (should be) just two alternative serializations of the
  same meaning. However, what constitutes the meaning of an archetype
  is
  not a trivial question.
 
 
 When specializing an archetype the name (and meaning) changes.
 When originally the Name node is ENTRY it can be changed in
 specialization to ENTRY:Observation
 Or into ENTRY:Observation:ClinicalFinding
 Or into ENTRY:Observation:ClinicalFinding:BodyTemperature
That's fine, but serializing is not specializing. Templates also allow
specializing (that is in a way what templates do) as does archetypes so
there's an overlap. But that's a separate (and important) issue. I was
asking about the possibility of having more compact serialization
formats.
 
 The names are different and therefore their meanings.
 Although all names are related to each other.
 
 
 
 
 
   They are more complex in places (because new branches) have been
   added, less complex in places (because branches are not used),
   more
   constrained in places than the pure parent archetype.
  Here I must confess I don't understand your use of the word
  complex.
  E.g. if there in an openEHR model is two specific named events in an
  observation which are expanded in the TDD (isn't it??) does this
  increase or decrease complexity?
 
 
 
 
 In a parent one node can allow zero to many siblings
 In a specialisation we can constrain it to any within the limits as
 specified by the parent.
 When allowed we can remove branches with zero-to-zero constraints and
 not use them at all.
 We can insert (when allowed) in places additional nodes (new banches)
 that were not in the parent.
Can you provide an example because I thought the latter was not allowed
(depending on what a branch is).
 
 
 
   
   
   To write generic transformations is not trivial, I expect.
   If possible at all.
  I do not agree. I believe this is what every implementer necessarily
  has
  to do, to provide a two-way transformation between a canonical form
  and
  any serialization and/or persistence form with a different set of
  requirements (query performance, OLTP vs. OLAP, space requirements,
  legacy systems integration, etc. etc. etc.). Not trivial but done on
  a
  regular basis.
  
 
 
 Using the 13606 AOM based tools it must be possible to track the whole
 provenance of any archetype/template.
 (There is a problem known for Archetype Slots and keeping track of the
 original choices that were expressed.)
 Although the template might be a sub-set in places and a super set in
 other places,
as I said I don't think this is the case, but if there are issues these
should be discussed and straightened out. Do you have specific examples
or template functions where templates loosen constraints?
  all must conform to the Reference Model and all parent archetypes
 that were used in the chain of specializations.
 
 
 Without the complete set of artifacts the transformation will be NOT
 possible,
that's fair, but trivially true. Templates (or any
compositional-framework models) cannot be interpreted without having
access all it's constituent sub-models.
 Tracking all these changes that were made to the parent archetype
 
 
 
  
  Cheers,
  Daniel

TDS (and TDD) implementations?

[Daniel Karlsson]

Gerard, Ian, Thomas, thanks for all answers.

On Fri, 2013-06-14 at 11:17 +0100, Thomas Beale wrote:
 
 Let me clarify a few things here.
 
 There are many possible TDSs that can be generated from a given
 template. Some users want a 'flat schema' with minimal meta-data,
 which makes working with integration data easier, but a TDD (TDS XML
 document) - canonical transformer harder to write (it has to look up
 more from the archetypes.)
 
 Some users are happy with a fully featured schema that enables a
 nearly trivial TDD - canonical converter to be written.
 
 Some users want specific things like certain code annotations, or
 hidden node markers or whatever, which in some cases can only be
 obtained if they are in the annotations of the template or archetype
 (i.e. most archetypes / templates won't have these specific
 annotations).
 
 So, if we want to do a canonical - TDD transform from a primary
 openEHR repository, it means choosing which particular kind of TDS is
 being targetted. If there were a default TDS for openEHR (we should
 standardise on that), then canonical - TDD could be implemented and
 deployed, probably quite easily.

Such a standard TDS/TDD would have made the Swedish 2009-10 quality
registry project significantly easier and a lot of the criticism towards
openEHR could have been rejected. We more or less constantly had to
reply to questions as to why use archtypes/templates using up several
kilobytes when anyone can write an XSD for a specific use case using up
a fraction of that space. The obvious conclusion is that we (as in
Sweden) ourselves should have started that project. It's not always easy
being an openEHR advocate ;).

 It's just a question of what the community thinks is important.
 
 - thomas
 
 
 On 14/06/2013 08:41, Daniel Karlsson wrote:
 
  Hi Ian,
  
  On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote:
   Hi Erik,
   
   
   The Ocean TDD-canonical transform is available at
   
   
   http://openehr.codeplex.com/SourceControl/latest#176376
   
   
   
   look for TDD_to_openEHR.xsl
   
   
   As far as I know a generic reverse transform is not possible.
  How could that be? Is there something in the TDD format that is not in
  the RM format? The intuition tells me that it should be easier going
  from the rich RM format to the TDD format than in the opposite
  direction. What are the specific issues that make a reverse
  transformation problematic? Could anything be changed to make the
  transformation possible?
  
  /Daniel
   
   There are at least 3 or 4 companies using TDD as part of their CDR
   offering. 
   
   
   It would be good to make this part of the managed standard and public
   spec .
   
   
   Ian 
   
   
   
   On 30 May 2013 10:21, Erik Sundvall erik.sundvall at liu.se wrote:
   Hi!
   
   
   Which projects and products out there support TDS (Template
   Data Schema)? And do they support conversion of TDDs (Template
   Data Documents) to standard canonical openEHR RM instances
   (in e.g. XML)? Is there any available XSLT, webservice or
   other thing that can convert bidirectionally between TDD and
   openEHR RM-based instances?
   
   
   What about a TDS specification? Is there any published or
work-in-progress document? If not is there any entity, group
   or person that could/should be sponsored or bribed to produce
   such a thing? :-) It seems to be on the
   roadmap http://www.openehr.org/programs/specification/roadmap and 
   described there anyway...
   
   
   I think TDS is an essential component in the toolbox in
   practical openEHR integration projects but without a public
   spec, it will be harder to take seriously and hard to make
   compatible implementations.
   
   
   (ExampleTDS-info for people not familiar with the
   approach: 
   http://www.mz.gov.si/fileadmin/mz.gov.si/pageuploads/eZdravje/Novice/gradiva_predstavitve_dogodkov/Open_EHR/7_integration.pdf)
   
   
   Best regards,
   Erik Sundvall 
   Tel: +46-72-524 54 55
   LiO: erik.sundvall at lio.se 
   http://www.lio.se/Verksamheter/IT-centrum/
   LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/
   
   ___
   openEHR-technical mailing list
   openEHR-technical at lists.openehr.org
   
   http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
   
   
   
   
   ___
   openEHR-technical mailing list
   openEHR-technical at lists.openehr.org
   http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
  

Erik Sundvall's PhD Defence - Online Edition

[Daniel Karlsson]

Dear All,
The video will be on YouTube immediately after the defence. A feature of 
hangout on air. Same link used. /Daniel

Bert Verhees bert.verhees at rosa.nl skrev:



Very good, I appreciate this transparancy very much. I hope it will be 
available afterwards on Youtube.

Bert


On 02/15/2013 08:41 AM, Kalra, Dipak wrote:
Dear Daniel,

In order to be ready and to test the connection, I have logged in to the link 
you provided below. Is there another link I should follow, or button I should 
click on screen, to activate the video link?

With best wishes,

Dipak

Dipak Kalra
Clinical Professor of Health Informatics
Director, Centre for Health Informatics and Multiprofessional Education
University College London
Holborn Union Building, Highgate Hill, London N19 5LW
Phone: +44-20-7288-5966

President, The EuroRec Institute
Honorary Consultant, The Whittington Hospital NHS Trust, London

On 14 Feb 2013, at 21:00, Daniel Karlsson daniel.karlsson at 
liu.semailto:daniel.karlsson at liu.se wrote:

Dear Everyone,

Erik Sundvall's PhD defence will be broadcasted online tomorrow at 9.15 CET 
(8.15 UTC)

https://plus.google.com/events/ci7smrge59khogjuleabsv3mi7o

For more information, see http://www.imt.liu.se/people/erisu/2013/phd/

Cheers,
Daniel Karlsson


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.orgmailto:openEHR-technical at 
lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




___
openEHR-technical mailing list
openEHR-technical at lists.openehr.orgmailto:openEHR-technical at 
lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130215/172ee2a2/attachment-0001.html

Erik Sundvall's PhD Defence - Online Edition

[Daniel Karlsson]

Dear Everyone,

Erik Sundvall's PhD defence will be broadcasted online tomorrow at 9.15 
CET (8.15 UTC)

https://plus.google.com/events/ci7smrge59khogjuleabsv3mi7o

For more information, see http://www.imt.liu.se/people/erisu/2013/phd/

Cheers,
Daniel Karlsson


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130214/d42c7099/attachment.html

Units, Quantities, etc

[Daniel Karlsson]

Hi Grahame,

Wed 2012-03-21 klockan 10:26 +0100 skrev Grahame Grieve:

 Hi Daniel
 
 No one is talking about abandoning what we have. The only question is about 
 the way that the casual measurements of countable discrete things where the 
 ucum unit is 1 are handled. I think that we're agreed that openEHR and, for 
 that matter, HL7 v2 and v3 haven't go this right yet. In the openEHR context, 
 the question is, how should this be done?

Why not just treat numbers (or counts) as any other quantity? There
might be a case for providing a field for specifying the kind of
quantity in the DV_QUANTITY class, but as in the example below, this is
often includes more complex terminology-information model constructs
than a single field.

 
  tablets 500 mg paracetamol is not just a point of reference for
  representing the number quantity but part if of the quantity being
  observed (or stated). 
 
 I don't think this is true. Mostly, we look for codes for what is measured, 
 and the codes don't include that part. So if you, as v3/CDA do, say that that 
 is part of the thing that is measured, you are asking people to do an 
 impossible feat of post-coordination.

Well, I still think it's true! What's in a code and what's not is a
matter of the terminology binding assumptions made in the specific
situation. This kind of post-coordination (depending on what is meant
by this term) is happening constantly with e.g. laboratory medicine
where the kind of property observed is stated using a code from a
terminology like LOINC or, even better, NPU ;). This code does however
in most cases not specify the procedure to a sufficient degree so this
information is added in the message thereby adding to the meaning of the
code. The same is done for sample material and sample location. I would
prefer this solution to overloading the unit with things that break the
assumptions of metrology.

/Daniel

 
 Grahame
 
 On 19/03/2012, at 9:26 PM, Daniel Karlsson daniel.karlsson at liu.se wrote:
 
  Dear all,
  
  On s?n, 2012-03-18 at 13:57 +0100, Grahame Grieve wrote:
  Are discrete units only encountered in administrative directives? Do
  you prohibit people from making observations or measurements that
  include discrete units such as puffs, tablets, patches, vials, strips etc?
  
  There are examples of counting observables in both the laboratory and
  clinical domains like number of erythrocytes in urine, number of
  complement C3b receptors on thrombocytes, number of petechiae of skin
  per cm^2.
  
  If for example assuming the SI system base quantities, the kind of
  quantity is number with N as symbol and 1 or one as the unit.
  
  Comparing to another commonly known kind of quantity, length, and the
  unit meter, 1.83 m means 1.83 times the length of the Paris meter.
  Further, my body height quantity inheres in my body and the unit meter
  may be used to represent the length on a ratio scale, i.e. my body
  height = 1.83 m or 1.83 times the Paris meter. However, this quantity
  may be represented using other units such as the International foot.
  
  Going back to tablets, in 2 tablets 500 mg paracetamol the part
  tablets 500 mg paracetamol is not just a point of reference for
  representing the number quantity but part if of the quantity being
  observed (or stated). This part cannot be exchanged and thus cannot be a
  unit.
  
  The DV_QUANTITY class has no attribute for specifying the kind of
  quantity of which the magnitude field is a result of observation (or
  decision). Previously, this has been managed within archetypes, e.g. the
  systolic blood pressure quantity is referred to by binding the at0004
  code to the term Systolic and through this node's context within the
  archetype. In instances, there is no reference to any kind of quantity
  apart from units, which do not fully describe the kind of quantity, and
  any reference to the archetype on which the instance is based.
  
  Thus, my 2-cent suggestion is to stay on the path, keep DV_QUANTITY
  clean, and manage any issues around representation of doses in
  archetypes.
  
  Finally, there is the whole science of metrology backing this up. Please
  refrain from giving this solid ground up.
  
  Regards,
  Daniel
  
  
  why?
  
  HL7 does because we claim that you have to have UCUM codes
  so the data can be computable. If people simply want to exchange
  it in a structured but non-computable fashion... they can go to hell.
  And as for computable: we insist on a ucum code, and then say
  that for these discrete unit kind of things, well, you just put 1 for
  countable units, and then put the effective unit somewhere else -
  somewhere that no one can actually pull off in practice - because
  this is more computable. Huh? We do not make sense on this.
  
  So much for HL7... what's openEHR's excuse?
  
  Grahame
  
  
  On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale
  thomas.beale at oceaninformatics.com wrote:
  
  As Grahame mentioned on an earlier post

Units, Quantities, etc

[Daniel Karlsson]

Dear all,

On s?n, 2012-03-18 at 13:57 +0100, Grahame Grieve wrote:
 Are discrete units only encountered in administrative directives? Do
 you prohibit people from making observations or measurements that
 include discrete units such as puffs, tablets, patches, vials, strips etc?

There are examples of counting observables in both the laboratory and
clinical domains like number of erythrocytes in urine, number of
complement C3b receptors on thrombocytes, number of petechiae of skin
per cm^2.

If for example assuming the SI system base quantities, the kind of
quantity is number with N as symbol and 1 or one as the unit.

Comparing to another commonly known kind of quantity, length, and the
unit meter, 1.83 m means 1.83 times the length of the Paris meter.
Further, my body height quantity inheres in my body and the unit meter
may be used to represent the length on a ratio scale, i.e. my body
height = 1.83 m or 1.83 times the Paris meter. However, this quantity
may be represented using other units such as the International foot.

Going back to tablets, in 2 tablets 500 mg paracetamol the part
tablets 500 mg paracetamol is not just a point of reference for
representing the number quantity but part if of the quantity being
observed (or stated). This part cannot be exchanged and thus cannot be a
unit.

The DV_QUANTITY class has no attribute for specifying the kind of
quantity of which the magnitude field is a result of observation (or
decision). Previously, this has been managed within archetypes, e.g. the
systolic blood pressure quantity is referred to by binding the at0004
code to the term Systolic and through this node's context within the
archetype. In instances, there is no reference to any kind of quantity
apart from units, which do not fully describe the kind of quantity, and
any reference to the archetype on which the instance is based.

Thus, my 2-cent suggestion is to stay on the path, keep DV_QUANTITY
clean, and manage any issues around representation of doses in
archetypes.

Finally, there is the whole science of metrology backing this up. Please
refrain from giving this solid ground up.

Regards,
Daniel

 
 why?
 
 HL7 does because we claim that you have to have UCUM codes
 so the data can be computable. If people simply want to exchange
 it in a structured but non-computable fashion... they can go to hell.
 And as for computable: we insist on a ucum code, and then say
 that for these discrete unit kind of things, well, you just put 1 for
 countable units, and then put the effective unit somewhere else -
 somewhere that no one can actually pull off in practice - because
 this is more computable. Huh? We do not make sense on this.
 
 So much for HL7... what's openEHR's excuse?
 
 Grahame
 
 
 On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale
 thomas.beale at oceaninformatics.com wrote:
 
  As Grahame mentioned on an earlier post, the question of units is thorny.
  Although we technical people would like to mandate UCUM or some other
  well-designed computable syntax, on its own, it won't work. There seem to be
  two reasons for this:
 
  it doesn't take care of the need for a displayable form of units, e.g. the
  computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu
  followed by 'g')
  it doesn't take care of 'units' like puffs, tablets, patches, vials, strips,
  and other discrete delivery units
  it doesn't take care of discrete delivery units per time, e.g. '2 puffs /
  hour'
 
  Grahame and others have already done a lot of thinking on this here - there
  are a lot of excellent examples from Linda Bird on the Singapore programme.
 
  The more I think about the last two above, the more I think it is not about
  quantities per se but about an administration directive (how the patient
  should take something). Trying to make Quantity do that kind of stuff
  doesn't make sense to me - there is obviously a Quantity to indicate the
  dose in scientific form, but another data element may be needed to indicate
  how (in what discrete measures) to take the medication.
 
  I would therefore expect a distinct data element in the Medication Cluster
  archetype rather than a re-engineered Quantity type to deal with these last
  two. For the first one - displayable v computable, we will need a CR to
  change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a
  second units field.
 
  Some of my earlier thoughts are actually on the above wiki page - the
  concept of a DiscretisedQuantity type inheriting from Quantity, which I
  think is also a reasonable alternative.
 
  what do others think?
 
  - thomas
 
  ___
  openEHR-technical mailing list
  openEHR-technical at lists.openehr.org
  http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 
 
 

termbinding constraints in the archetype editor

[Daniel Karlsson]

Jostein,

as a possible work-around, we have used internal at-codes and mapped
those at-codes to the external terminology. This, of course, only works
if the number of allowed codes is limited, which have been the case in
our projects so far. This also has the benefit that the archetype does
not depend on external (terminology server) resources.

If the terminology used is SNOMED CT, IHTSDO will (eventually) provide a
standard for constraining expressions which will be applicable. This
would though have to be implemented in your terminology server.

Out of curiosity, what terminology server are you using?

Regards,
Daniel
-- 
Daniel Karlsson, PhD
Department of Biomedical Engineering/Medical Informatics
Link?pings universitet
SE-58185 Link?ping
Sweden
Phone: +46 13 286762, Cellular: +46 70 8350109, Skype: imt_danka



Tue 2012-01-10 klockan 10:55 +0100 skrev Jostein Ven:
 Everybody,
 
 I am trying to bind an attribute in an archetype to a value set from a
 terminology server. The data in the termserver is availiable through
 web services. In practice, it should thus be possible to specify a URI
 in an archetype constraint for the elementattribute. Can't figure out
 how this is meant to be done in AE. Anyone with experience of how to
 do this in practice? 
 
 Does anyone know what the AE does when you enter the interface screen.
 Is the constraint executed, if not, when is the constraint executed
 (or is it executed at all?).
 
 References to AE user manual is also welcome. Can't find this.
 
 
 All the best 
 Jostein Ven
 Senior adviser
 Norwegian Directorate of Health
 
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/696dc33d/attachment.html

Sample OpenEHR records

[Daniel Karlsson]

Dear Everyone,

sorry for the delay, we at Link?ping University have created a number of
XML instance compositions, not very fancy but we would be willing to
share them. I'll just try to find somewhere to put them.

/Daniel

On tor, 2011-03-03 at 09:55 +0100, Roger Erens wrote:
 Hi Koray, Hong Yul,
 
 I am also interested in receiving a few examples to test with.
 Would it be possible (and allowed) to have these data publicly
 available on the openEHR wiki?
 
 Cheers,
 
 Roger
 
 On Thu, Mar 3, 2011 at 05:55, Koray Atalag k.atalag at auckland.ac.nz wrote:
  Hi Diego, was on travel so just reckoned this...Yes we do have instances, 
  but probably quite odd. It is made up of a very detailed endoscopy report 
  serialised as XML.
 
  I'll ask Hong Yul, the technical hero behind it, to send a few examples to 
  you.
 
  HYY??
 
  Cheers,
 
  -koray
 
 
  -Original Message-
  From: openehr-technical-bounces at openehr.org 
  [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Diego Bosc?
  Sent: Thursday, 3 March 2011 5:06 p.m.
  To: For openEHR technical discussions
  Subject: Re: Sample OpenEHR records
 
  For the lack of responses I assume that they are not available. Is
  there at least an openEHR XML instance validator? we could try to make
  the instances from scratch and validate them.
 
  2011/3/1 Jesus Bisbal jesus.bisbal at upf.edu
 
  I second that. Very interested.
  I posted a similar request to this list a couple of years ago. It proved 
  difficult.
  Indeed, having such sample data is essential for testing, learning the 
  models, etc
 
  All the best.
 
  Jes?s
 
  On 01/03/2011 1:11, Diego Bosc? wrote:
 
  I would be also interested in this.
 
  2011/3/1 Tiago Pedrosa pedrosa at ipb.pt:
 
  Hi everyone,
 I'm looking for sampling OpenEHR records data. I will like to feed 
  my
  repository with some sample data to make some test and try new
  services, does anyone knows where can I get that ?
 Thank you for your time, best regards,
 
  Tiago Pedrosa
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
  --
 
  
 
  Jes?s Bisbal-Riera 
  http://www.dtic.upf.edu/~jbisbal
  Center for Computational Imaging  Simulation Technologies in Biomedicine 
  (CISTIB)
  Information  Communications Technologies Department
  Universitat Pompeu Fabra http://www.upf.edu
  c/ Tanger, 122-140 Work Ph: +34 93 542 29 51 / 25 00
  08018 Barcelona, Spain Fax: +34 93 542 25 17
  and
  Networking Biomedical Research Center on Bioengineering, Biomaterials
  and Nanomedicine (CIBER-BBN)
  Barcelona, Spain
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Sample OpenEHR records

[Daniel Karlsson]

Dear Everyone again,

here are some simple COMPOSITION samples, with some Swedish inside...

http://www.imt.liu.se/~danka/AQLTestData.zip

/Daniel

On tor, 2011-03-03 at 09:55 +0100, Roger Erens wrote:
 Hi Koray, Hong Yul,
 
 I am also interested in receiving a few examples to test with.
 Would it be possible (and allowed) to have these data publicly
 available on the openEHR wiki?
 
 Cheers,
 
 Roger
 
 On Thu, Mar 3, 2011 at 05:55, Koray Atalag k.atalag at auckland.ac.nz wrote:
  Hi Diego, was on travel so just reckoned this...Yes we do have instances, 
  but probably quite odd. It is made up of a very detailed endoscopy report 
  serialised as XML.
 
  I'll ask Hong Yul, the technical hero behind it, to send a few examples to 
  you.
 
  HYY??
 
  Cheers,
 
  -koray
 
 
  -Original Message-
  From: openehr-technical-bounces at openehr.org 
  [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Diego Bosc?
  Sent: Thursday, 3 March 2011 5:06 p.m.
  To: For openEHR technical discussions
  Subject: Re: Sample OpenEHR records
 
  For the lack of responses I assume that they are not available. Is
  there at least an openEHR XML instance validator? we could try to make
  the instances from scratch and validate them.
 
  2011/3/1 Jesus Bisbal jesus.bisbal at upf.edu
 
  I second that. Very interested.
  I posted a similar request to this list a couple of years ago. It proved 
  difficult.
  Indeed, having such sample data is essential for testing, learning the 
  models, etc
 
  All the best.
 
  Jes?s
 
  On 01/03/2011 1:11, Diego Bosc? wrote:
 
  I would be also interested in this.
 
  2011/3/1 Tiago Pedrosa pedrosa at ipb.pt:
 
  Hi everyone,
 I'm looking for sampling OpenEHR records data. I will like to feed 
  my
  repository with some sample data to make some test and try new
  services, does anyone knows where can I get that ?
 Thank you for your time, best regards,
 
  Tiago Pedrosa
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
  --
 
  
 
  Jes?s Bisbal-Riera 
  http://www.dtic.upf.edu/~jbisbal
  Center for Computational Imaging  Simulation Technologies in Biomedicine 
  (CISTIB)
  Information  Communications Technologies Department
  Universitat Pompeu Fabra http://www.upf.edu
  c/ Tanger, 122-140 Work Ph: +34 93 542 29 51 / 25 00
  08018 Barcelona, Spain Fax: +34 93 542 25 17
  and
  Networking Biomedical Research Center on Bioengineering, Biomaterials
  and Nanomedicine (CIBER-BBN)
  Barcelona, Spain
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

XML Extracts availability

[Daniel Karlsson]

Dear Everyone,

there is a tool developed by Rong to generate openEHR (XML) instances
from a set of template (oet) files and a set of archetypes. We've used
it to make templates (like web-templates not openEHR templates) for
generating openEHR instances with patient data.

/Daniel

On Fri, 2011-01-07 at 14:06 +0100, Cati Mart?nez wrote:
 Hello, 
  
 does anybody know where could I find XML data extracts for OpenEHR or
 ISO 13606?
  
 Thank you.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110107/92b9e52a/attachment.html

Archetyping links

[Daniel Karlsson]

Dear Everyone,

what are the possibilites of constraining the LINK.target attribute
(DV_EHR_UIR datatype) in an archetype? This was possible in earlier
versions of the Ocean Archetype Editor (although its use never was clear
to me). Let's say that I want to constrain a link from an archetype to
only allow linkage to instances conforming a specific set of archetypes
(e.g. allowing linkage only to Diagnosis-archetype instances for links
with complication of meaning.) Is it allowed to use a regexp
constraint on the DV_EHR_URI and include the archetype id? Is it
guaranteed that the archetype id can be used in the path as in 11.2.3 in
Architecture overview in run-time systems?

Regards,
Daniel

Archetyping links++

[Daniel Karlsson]

Sorry, forgot the final question: Is this (see preceding email)
implemented in openEHR-based systems?

Regards again,
Daniel

-- 
Daniel Karlsson, PhD.
Department of Biomedical Engineering/Medical informatics
Link?pings universitet
SE-58185 Link?ping
Sweden
Tel. 013-227573, Mobil: 070-8350109, Skype: imt_danka

Decision Support was: MIE-2008

[Daniel Karlsson]

Hi Hugh,

ok, you got me ;), I tried but I could not find a case were there would
have been a value in knowing that two standings are (more or less) the
same, I think because the word standing is so obviously *well-enough*
defined in everyday English, even for a Swede! But what about e.g. the
various laboratory battery archetypes? I would think that to know when
there is an overlap between batteries is a good thing. E.g.
P-ALAT;cat.c. would be in at least a couple of batteries.

Also, I do not see this as a problem of bad or good archetyping, but as
an archetyping reproducibility problem.

Hi Gerard,

the problem, as I see it, is that the vocabulary have semantic
structures attached whether it is represented or not and these semantics
may interact with the semantics of the archetype, hence the grey zone.
As it is hard to draw the line reproducibly and as the boundaries may
move as both archetypes and terminologies evolve, some overlap may be
another good thing.

As a conclusion I would like to agree with Hugh that terminology needs
information models and vice versa and that the focus now should be to
build consensus on the areas surrounding the grey zone.

/Daniel

On Wed, 2008-06-11 at 09:23 +1000, Hugh Leslie wrote:
 Hi Daniel
 
 I would be interested in a real world use case where you need to know
 that standing has the same meaning in two different archetypes.  If
 archetypes are designed properly, then the semantics of the model are
 self contained as a single concept.  Specialisations of the model will
 maintain the same meaning of the contained elements, and the semantics
 of the contained elements relate to the whole concept.  I would
 contend, that in any examples where the same element needs to have the
 same meaning across different archetypes, it is probably because the
 design of the archetype is bad.
 
 Coding everything to that level has great implications in terms of
 cost - not only in terms of development, but also in terms of
 maintenance.  If there are compelling real world use cases for doing
 this, lets do it, otherwise lets do what is pragmatic and gets the job
 done as soon as possible.
 
 regards Hugh
 
  
 
 Daniel Karlsson wrote: 
  Hugh,
   
  

   The argument comes when you say that every data point in an archetype
   needs to be coded and here there are arguments both ways.  I would say
   that it is unnecessary to code every data point.  There is little
   benefit for instance in coding sitting, lying, standing, reclining n a
   blood pressure archetype.  The archetype contrains the value of
   position to these four values.  The values are in context and their
   meaning is clear to anyone using this archetype.  Translation is much
   easier as the archetype gives an absolute context for the meaning of
   the term.  Coding these terms in SNOMED would be so that you can query
   your health record for every standing item?  Its pretty unlikely
   that this would be a useful requirement.  Coding everything s going to
   be a very slow and enormously expensive process to get right.  It
   makes translation of archetypes much more difficult, especially for
   those many countries that don't (yet) have a SNOMED translation.
   Building archetypes is proving to be a very rapid and useful process.
   
  
  I think that there can be more reasons for binding archetype nodes to
  external terminologies apart from information re-use requirements in the
  query for everything standing example, e.g. to be able to express that
  standing in one archetype has the same meaning as standing in
  another archetype.
  
  Also, I didn't realise that I said that everything necessarily should be
  coded. Referring to David Markwell's report, he states (more or less)
  that things in the grey zone should be represented redundantly but he
  also states that terminology binding requirements should be driven by
  information re-use requirements. I agree with him on both points.
  
  /Daniel
  
  
  
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
  
  

 
 -- 
  
 Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI 
 Clinical Director 
 Ocean Informatics Pty Ltd 
 M: +61 404 033 767   E: hugh.leslie at oceaninformatics.com  W:
 www.oceaninformatics.com 
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Decision Support was: MIE-2008

[Daniel Karlsson]

Dear Everyone,

just to add another perspective, in the Galen project post coordination
was the norm while IHTSDO sits on a heritage of some 300 000 things
Snomed CT needs to take care of. Also, pre-coordination is (I think)
required for making fixed length identifiers. Still, Snomed CT is
unusable without post-coordination, making pre-coordinated entities for
everything in Snomed CT that has laterality would mean approcimately 700
000 entities.

/Daniel


On Thu, 2008-06-05 at 20:19 +1000, Hugh Leslie wrote:
 Hi Stef,
 
 SNOMED can be pre or post co-ordinated.  A pre coordinated term is
 something like left foot where the side is included as part of the
 whole code and there is a separate term for right foot.  There are
 many such codes in SNOMED.  A post coordinated term is one which is
 described by a number of codes i.e. foot, left.  This can get as
 complex as you like such as this example from wikipedia
 284196006|Burn of skin|:
246112005|Severity|=24484000|severe,
363698007|Finding Site|=
  (113185004|Structure of skin between fourth and fifth 
 toes|:272741003|Laterality|=7771000|left)
 We believe that building and querying for these complex post
 coordinated sentences is very difficult.  The marriage of archetypes
 and terminology is a good one as much of the complexity of trying to
 express these things in a terminology can be expressed more simply
 using an archetype with the terminology enabling inferencing.  
 
 hope this helps
 
 regards Hugh
 
 Stef Verlinden wrote: 
  Hi Ian and Gerard, 
  
  
  Could you please explain what post-coordination is and maybe provide
  an example of post- (and pre-?) coordination?
  
  
  Cheers,
  
  
  Stef
  
  Op 5-jun-2008, om 0:48 heeft Ian McNicoll het volgende geschreven:
  
most
   post-coordination (using modifiers in Snomed-space instead of
   Archetype/Template space) must end,
  
  
  
  
  
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

 
 -- 
  
 Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI 
 Clinical Director 
 Ocean Informatics Pty Ltd 
 M: +61 404 033 767   E: hugh.leslie at oceaninformatics.com  W:
 www.oceaninformatics.com 
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Decision Support was: MIE-2008

[Daniel Karlsson]

?
 In order to solve it we must look forward and reduce the 'grey zone'
 by acknowledging that most post-coordination (using modifiers in
 Snomed-space instead of Archetype/Template space) must end.
 
 
 Gerard

Realizing that the current Snomed CT Concept Model is not enough (today,
unfortunately by far) and that the tools for supporting constrained
post-coordination mainly are lacking, at least Snomed CT provides *some*
constraints on semantics in areas where openEHR provides none. Also, the
suggestion by David Markwell, I believe, is to represent semantics in
Snomed space *as well as* in the archetype space.

Also, I firmly believe that the grey zone will always exist as it is
the result of the concurrent use of two different models of semantics.
Thus, the boundary problem will not be solved, rather we will have to
develop methods that makes the grey zone related problems less
harmful.

Regards,
Daniel 

-- 
Daniel Karlsson, PhD
Department of Biomedical Engineering/Medical Informatics
Link?pings universitet
SE-58185 Link?ping
Sweden
Ph. +46 13 227573, +46 70 8350109

Decision Support was: MIE-2008

[Daniel Karlsson]

Hugh,
 

 The argument comes when you say that every data point in an archetype
 needs to be coded and here there are arguments both ways.  I would say
 that it is unnecessary to code every data point.  There is little
 benefit for instance in coding sitting, lying, standing, reclining n a
 blood pressure archetype.  The archetype contrains the value of
 position to these four values.  The values are in context and their
 meaning is clear to anyone using this archetype.  Translation is much
 easier as the archetype gives an absolute context for the meaning of
 the term.  Coding these terms in SNOMED would be so that you can query
 your health record for every standing item?  Its pretty unlikely
 that this would be a useful requirement.  Coding everything s going to
 be a very slow and enormously expensive process to get right.  It
 makes translation of archetypes much more difficult, especially for
 those many countries that don't (yet) have a SNOMED translation.
 Building archetypes is proving to be a very rapid and useful process.

I think that there can be more reasons for binding archetype nodes to
external terminologies apart from information re-use requirements in the
query for everything standing example, e.g. to be able to express that
standing in one archetype has the same meaning as standing in
another archetype.

Also, I didn't realise that I said that everything necessarily should be
coded. Referring to David Markwell's report, he states (more or less)
that things in the grey zone should be represented redundantly but he
also states that terminology binding requirements should be driven by
information re-use requirements. I agree with him on both points.

/Daniel