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 
mailto:pablo.pa...@cabolabs.com>> 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&q=snomed&type=

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 mailto:b...@dips.no>> 
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&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=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
___
openEHR-technical mailing list
openEHR-t

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 
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
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 , 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



-- 
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
<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 
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, 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]

In DV_CODED_TEXT there are three mandatory attributes: DV_TEXT.value, 
DV_CODE_PHRASE.terminology_id, DV_CODE_PHRASE.code_string, i.e. 50 % 
overkill only ;)


/Daniel

On 2016-05-18 11:11, Grahame Grieve wrote:

That's overkill - just have two fields, human and computable units.

Grahame

On 18 May 2016, at 7:05 PM, Daniel Karlsson <mailto:daniel.karls...@liu.se>> wrote:


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 
<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

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]

 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 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]

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  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

openEHR-technical Digest, Vol 18, Issue 38

[Daniel Karlsson]

d facilitates the use in other archetypes or templates as 
> >> defined in OpenEHR.
> >> 
> >> Vriendelijke groet,
> >> 
> >> Dr. William Goossen
> >> 
> >> Directeur Results 4 Care BV
> >> +31654614458
> >> 
> >> Op 28 aug. 2013 om 18:00 heeft openehr-technical-request at 
> >> lists.openehr.org 
> >> het volgende geschreven:
> >> 
> >>> Send openEHR-technical mailing list submissions to
> >>>   openehr-technical at lists.openehr.org
> >>> To subscribe or unsubscribe via the World Wide Web, visit
> >>> 
> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> >>> or, via email, send a message with subject or body 'help' to
> >>>   openehr-technical-request at lists.openehr.org
> >>> You can reach the person managing the list at
> >>>   openehr-technical-owner at lists.openehr.org
> >>> When replying, please edit your Subject line so it is more specific
> >>> than "Re: Contents of openEHR-technical digest..."
> >>> 
> >>> Today's Topics:
> >>>  1. Re: Polishing node identifier (at-codes) use cases.
> >>> (Gerard Freriks)
> >>> 
> >>> --
> >>> Message: 1
> >>> Date: Wed, 28 Aug 2013 13:26:14 +0200
> >>> From: Gerard Freriks 
> >>> To: For openEHR technical discussions
> >>>   
> >>> Subject: Re: Polishing node identifier (at-codes) use cases.
> >>> Message-ID: 
> >>> Content-Type: text/plain; charset="windows-1252"
> >>> David,
> >>> Can I summarise it for my understanding as:
> >>> - AT codes are pointers to an 'ontology'.
> >>> - AT codes can be considered symbols that represent a particular 
> >>> concept
> >>> - The 'ontology' provides a name that will be used to display the name of 
> >> a node (concept) in an archetype.
> >>> - When a node is specialised the node name used will indicate a new 
> >> concept (its meaning has changed)
> >>> - When the archetype is specialised ideally the new concept in the 
> >> specialisation is a subordinate concept.
> >>> - When a Node is specialised the standard does not prescribe that the new 
> >> concept is a sub-set of the previous one.
> >>> - The question is: is each Node (and the concept it represents) unique or 
> >> not.
> >>> - The question is: is it obligatory that each node in the archetype 
> >> carries a unique code  of the form AT .
> >>> My answers to both questions are:
> >>> - Each archetype node is  a unique concept that must have attached to it 
> >> a unique identifier.
> >>> - Archetype editors must support this.
> >>> And I would like to add:
> >>> - When specialising each specialised concept must be a subset of its 
> >> previous one.
> >>> 
> >>> Gerard Freriks
> >>> +31 620347088
> >>> gfrer at luna.nl
> >>> On 28 aug. 2013, at 09:13, David Moner  wrote:
> >>>>>>> I'll try to summarize the origin of the different views we have 
> >> regarding this topic and maybe this can be also useful to see why this is 
> >> not just a configuration problem of the tools.
> >>>> We can find the explanation of node identifiers in two places (I use the 
> >> latest drafts, I think):
> >>>> - In AOM 1.5 specifications, page 47: "Semantic identifier of this node, 
> >> used to distinguish sibling nodes of the same type. [Previously called 
> >> ?meaning?]. Each node_id must be defined in the archetype ontology as a 
> >> term code."
> >>>> - In ADL 1.5 specifications, page 26: "In cADL, an entity in brackets of 
> >> the form [at] following a type name is used to identify an object 
> >> node, 
> >> i.e. a node constraint delimiting a set of instances of the type as 
> >> defined 
> >> by the reference model." and  "A Node identifier is required for any 
> >> object 
> >> node that is intended to be addressable elsewhere in the same archetype, 
> >> in 
> >> a specialised child archetype, or in the runtime data and which would 
> >> otherwise be ambiguous due to sibling object nodes"
> >>>> The definition in AOM is the one followed by the openEHR editor, i.e. a 
> >> node identifier or at code is just a pointer to the ontology section 
> >> and a mechanism to distinguish sibling nodes. Thus, wherever it is not 
> >> needed, the tool does not introduce that code in order not to dirty the 
> >> ontology section.
> >>>> The  first part of the definition in ADL is the one followed in LinkEHR 
> >> and, in our opinion, more correct formally. When you introduce an 
> >> archetype 
> >> constraint for a C_OBJECT you are in fact creating a definition of a type 
> >> (a sub-type of the more generic type defined by the reference model class) 
> >> that will be used to create a subset of instances. We have to distinguish 
> >> this sub-type from the RM type, and since the class name cannot be 
> >> changed, 
> >> the only solution is to use the at as type identifier. In other words, 
> >> our interpretation is that at codes are unique identifiers of each 
> >> type 
> >> defined in the archetype, that may be also used to link to the ontology 
> >> section, but that is the optional part. In fact, the only exception to 
> >> this 
> >> would be when you create constraints using a path, because then you are 
> >> just navigating through the RM but do not change 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

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  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/gradiv

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 
> 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 th

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 
> 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 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  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

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  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 mailto: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.org<mailto: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<mailto: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>

Developers' workshop at MEDINFO2013 in Copenhagen.

[Daniel Karlsson]

Dear All,
The submission deadline for workshops is actually the 10th of January. 
http://www.medinfo2013.dk/submissions
/Daniel

Shinji KOBAYASHI  skrev:


Dear all,

I would like to propose a workshop at the next MEDINFO.
If you are interested in this plan, please reply on this mailing
list or direct to me.
We had two good workshops at MEDINFO in  2007 and 2010.
The coming MEDINFO will be held at 20-23 August 2013.
http://www.medinfo2013.dk/

The paper and proposal deadline is closing, 10 December, 2012.
However, I think we have enough time to discuss to have a good
workshop proposal.
In the contrast of established paper discussion, workshop can discuss
about on going materials. Even though we can get information about
openEHR related development, face-to-face discussion could share
more experience.
At this workshop, I think it does not matter what you did, but what you are
doing. I wish to share our passion.

Regards,
Shinji KOBAYASHI

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

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  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 

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
>  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>

Multiple values in C_DV_ORDINAL constraints

[Daniel Karlsson]

Hi Everyone,

a problem with Ian's score is that it's not an ordinal scale, but a
partial order. E.g. for the skin type variable, "healthy" is ordered in
relation to the other elements, but "tissue paper"* is not ordered in
relation to "dry" or "oedematous". In the openEHR Archtype Profile the
VCOV rule disallows DV_ORDINALS with identical values in the
C_DV_ORDINAL list, thereby only allowing total orders. This could be
changed though!

Don't know how this scoring system is used, but "oedematous" and "dry"
can not reasonably be seen as terminological synonyms!

Regards,
Daniel

*what does "tissue paper" really mean in this context, especially in
relation to dry??
Fri 2011-09-23 klockan 13:58 +0200 skrev Rong Chen:

> Hi Ian,
> 
> 
> 
> I my opinion either the ordinal nor ordinal constraint prohibit
> ordinal terms with duplicated values in the same ordinal constraint.
> 
> 
> It's probably the editor that needs to be fixed to cope with this
> requirement.
> 
> 
> Cheers,
> Rong
> 
> 
> On 2 August 2011 00:22, Ian McNicoll
>  wrote:
> 
> Hi Thomas,
> 
> 
> 
> I am not quite sure what you are saying here, though I agree,
> in essence, the scoring system, like most others, is
> flattening a variety of patient findings into a single term
> which also then carries a score. The problem is that whilst
> the ordinal terms are unique, the related values are not and
> can have duplicates.
> 
> 
> So is this a valid ordinal ? ordinal constraint?
> 
> 
> Ian
> 
> 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
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care  www.phcsg.org
> 
> 
> 
> 
> 
> On 1 August 2011 17:04, Thomas Beale
>  wrote:
> 
> If we consider this an ordinal based model, in which
> numbers which have multiple possible values, e.g. skin
> type: 1 is for tissue paper dry, oedematous, etc -
> this would be modelling using terminological synonyms
> for a notional term whose meaning was something like
> 'waterlow skin type 1'. 
> 
> - thomas
> 
> 
> 
> 
> On 01/08/2011 16:17, Ian McNicoll wrote: 
> > 
> > I have come across an interesting example of where
> > we might want to model an ordinal constraint where
> > the values associated with each term are not unique.
> > The example is the Waterlow Score
> > http://www.judy-waterlow.co.uk/downloads/Waterlow%
> > 20Score%20Card-front.pdf If you look at the
> > bottom-right corner "Major surgery / Trauma" you
> > will se that two terms have identical values.
> > Currently the openEHR Archetype Editor will not let
> > me add duplicate values with separate terms. It is
> > not clear (at least to me) from the specifications
> > that this behaviour is correct. Is this a CR for the
> > Archetype Editor, a CR to the Ref Model, or a clever
> > alternative modelling suggestion to me? Regards, Ian
> > 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
> > openEHR Clinical Knowledge Editor
> > www.openehr.org/knowledge Honorary Senior Research
> > Associate, CHIME, UCL BCS Primary Health Care
> >  www.phcsg.org
> > 
> > 
> > 
> > ___
> > openEHR-clinical mailing list
> > 
> > openEHR-clinical at openehr.org
> > 
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical 
> 
> 
> 
> 
> -- 
> Ocean Informatics
> Thomas Beale
> Chief Technology Officer,
> Ocean Informatics
> 
> Chair Architectural Review
> Board, openEHR Foundation 
> Honor

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  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 
> >>
> >> 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 :
> >>
> >> 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,

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  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 
> >>
> >> 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 :
> >>
> >> 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: 

openEHR and iPhone/iPad anyone?

[Daniel Karlsson]

Dear Everyone,

we here in Link?ping are now running a student project were the EHR is
to be viewed on a pad, most probably using HTML(5?) for presentation of
data generated from our openEHR system (which is based on the Java
reference implementation). This is a first run for us and a very small
project but will hopefully give us a feel for what could be possible.
The project is supposed to run during the autumn and has just recently
started and, I should also add, the students doing the project are in
the beginning of their training. Hopefully we can continue on from this
project with master students or similar.

Regards,
Daniel

On Fri, 2010-09-24 at 12:11 +0200, Athanasios Anastasiou wrote:

> Hello Olof and everyone
> 
> I think that the iPad / iPhone devices could be of some assistance as 
> far as the interface to an openEHR enabled application is concerned.
> 
> It could perhaps enable a more tactile manipulation of the entities 
> contained in the health record...(tactile and efficient, i wish, i.e not 
> a gimmick)
> 
> But the actual modification of EHR content and interaction with the 
> server does not need to occur on the device itself, this would certainly 
> complicate things a lot.
> 
> I vaguely remember Erik Sundvall talking about a REST approach to 
> handling openEHR content. In this case, all the iPad / iPhone / 
> iWhatever device would need to do is POST (or GET) data from specific 
> URLs just like many other web applications do now.
> 
> But until we hear any more news from that front, i suppose that you will 
> have to rely on a web application based on either the java reference 
> implementation or OSHIP. In this case, you could work a little bit with 
> the presentation layer through CSS (and the fact that the page is 
> accessed by a mobile device) to perhaps adjust it to the iPad / iPhone 
> screen size or other property.
> 
> I hope this helps.
> 
> All the best
> Athanasios Anastasiou
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 23/09/2010 11:25, Olof Torgersson wrote:
> > Hi,
> >
> > Is there anyone who's done any work related to openEHR for the iPhone/iPad?
> >
> > I guess one would need an implementation of the reference model etc in 
> > Objective-C since that's the only supported language on the platform.
> >
> > If you are working on this or interested in the topic then I would be 
> > interested in knowing about it.
> >
> > regards
> >
> > Olof Torgersson
> >
> > ---
> > Olof Torgersson
> >
> > Associate Professor
> > Department of Applied Information Technology
> > Chalmers University of Technology and G?teborg University
> > SE-412 96 G?teborg, Sweden
> >
> > email: olof.torgersson at chalmers.se
> > phone: +46 31 772 54 06
> >
> >
> > ___
> > 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
-- next part --
An HTML attachment was scrubbed...
URL: 

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

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

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 "standing"s 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 Gerard and Everyone,

On Tue, 2008-06-10 at 20:51 +0200, Gerard Freriks wrote:
> I agree with you that the grey zone is a relic from the past we have
> to deal with. Never the less, I want to argue that we have to reduce
> this grey-zone. By means of my suggestion to do post-coordination as
> much as possible in the archetype. 
> 
> The main reason is: - In language post coordination is done in the
> syntaxis and not in the dictionary.

I didn't say that the grey zone is a relic of the past but, quite
differently, a fact we need to acknowledge and relate to. The main
reason: terminologies are not just merely dictionaries but make
assumptions of semantics that interact with assumptions of semantics
made in archetypes. Also, in terminological languages, representations
of the semantics may be processed formally.

/Daniel

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

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]

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

Specialisation

[Daniel Karlsson]

Dear Everyone,

actually I was going to re-state the questions to the technical list,
but will cross post it to the clincial (will I be banned???).

For the clinical list read the original message below:

For the technical list, I would still like to have the details of
specialisation laid out. Are constraints inherited and thus implicit in
the specialised archetypes' definitions? Then, in the BW/BWB example,
are also the weight gain/loss inherited (which according to my layman
understanding is not very sensible for birth weight).

Clear semantics of specialisation would be necessary to bring further
any discussion on support from tools in this area.

/Daniel

Daniel Karlsson, PhD
Department of Biomedical Engineering/Medical Informatics
Link?pings universitet
SE-58185 Link?ping
Sweden

On Sun, 2007-12-09 at 19:06 +0100, Tim Cook wrote:
> Hi Daniel,
> 
> I would suggest that you re-post this on the clinical mailing list.
> 
> Cheers,
> Tim
> 
> 
> 
> On Mon, 2007-12-03 at 12:55 +0100, Daniel Karlsson wrote:
> > Dear Everyone,
> > 
> > Background:
> > We are in Sweden starting a number of clinical archetype-construction
> > projects and we are hoping to re-use as much as possible from the
> > openEHR repository by specialisation.
> > 
> > So to my problem:
> > Looking at the openEHR-EHR-OBSERVATION.body_weight.v1 archetype
> > (hereafter named BW) and the
> > openEHR-EHR-OBSERVATION.body_weight-birth.v1 archetype (BWB), BWB does
> > not seem to be a specialisation of BW. BWB specifies the event to be
> > birth and clothing state to be naked, but relaxes the unit restriction
> > to allow grams (with "g" as the abbreviated from, not "gm", see ISO
> > Guide 31, item 3.1-a).
> > 
> > Then to my specific questions:
> > 1. Are the BW and BWB wrong and should be corrected?
> > 2. Can BWB be understood without BW or must each restriction be stated
> > explicitly? E.g., does BWB inherit the protocol restriction from BW? 
> > 3. What about weight gain and weight loss in BW?
> > 
> > Best Regards,
> > Daniel

Specialisation

[Daniel Karlsson]

Dear Everyone,

Background:
We are in Sweden starting a number of clinical archetype-construction
projects and we are hoping to re-use as much as possible from the
openEHR repository by specialisation.

So to my problem:
Looking at the openEHR-EHR-OBSERVATION.body_weight.v1 archetype
(hereafter named BW) and the
openEHR-EHR-OBSERVATION.body_weight-birth.v1 archetype (BWB), BWB does
not seem to be a specialisation of BW. BWB specifies the event to be
birth and clothing state to be naked, but relaxes the unit restriction
to allow grams (with "g" as the abbreviated from, not "gm", see ISO
Guide 31, item 3.1-a).

Then to my specific questions:
1. Are the BW and BWB wrong and should be corrected?
2. Can BWB be understood without BW or must each restriction be stated
explicitly? E.g., does BWB inherit the protocol restriction from BW? 
3. What about weight gain and weight loss in BW?

Best Regards,
Daniel
-- 
Daniel Karlsson, PhD, assistant professor
Department of Biomedical Engineering/Medical informatics
Link?pings universitet
SE-581 85  Link?ping
Sweden
Ph. +46 13 227573, +46 70 8350109