RE: Terminology bindings ... again

[Koray Atalag]

Hi Tom,

I think min_version can be problematic as certain terms can be deprecated in 
future versions and then this naming could be misleading. That said for SNOMED 
it’ll still be present in future releases just marked as inactive. For other 
terminologies this cannot be guaranteed. BTW SNOMED uses term Effective Time

Cheers,

-koray

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Tuesday, 18 July 2017 2:19 a.m.
To: Openehr-Technical; For openEHR clinical discussions
Subject: Terminology bindings ... again

Recently we discussed terminology bindings. We probably still have not got them 
right, but we don't have a model of what we think they should be. I posted a 
quick idea of a possible more structured version:



term_bindings = <

["snomed_ct"] = <

["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) 
<

   target =  -- Apgar score at 1 
minute

   notes = <"some notes">

   min_version = <"2017-02-01">

   etc = <"etc">

>

["id26"] = (CONSTRAINT_BINDING) <

 target = <"71388002 |Procedure| : 405815000 |Procedure device| 
 =  122456005 |Laser device| , 260686004 |Method|  =  129304002 |Excision - 
action| ,405813007 |Procedure site - direct|  =  1549700l6 |Ovarian structure|">

min_version = <"2017-04-01">

 notes = <"some notes">

 etc = <"etc">

 >

>

>

I noted that the right hand side of a binding can be a few different things, 
each of which would be accompanied by various meta-data, including:

  *   a single concept code
  *   a single code or other id referring to an external value set in an 
external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is 
no standard that I know of)
  *   a composition expression that refers to a more refined concept
  *   possible a constraint expression that locally determines a value set 
intensionally, to be resolved by application to the Terminology service.
I'd rather avoid the last, because of the brittleness of intensional ref-set 
query syntax expressions. In any case, we need a better idea of what meta-data 
are needed. E.g.:

  *   something to do with (min) version of terminology required for the 
reference to be valid
  *   something to do with purpose?
  *   other notes - a tagged list of basic types?
I would like to get a better idea of the requirements.

- thomas

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: [FORGED] Re: A little community coordination

[Koray Atalag]

Hi Pablo, great initiative!

I’ve filled my response…Looking forward to seeing results

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pablo Pazos
Sent: Sunday, 21 May 2017 10:46 a.m.
To: For openEHR technical discussions
Subject: [FORGED] Re: A little community coordination

Hi all, this is the form: https://goo.gl/forms/oloBgwQlLU3NGrbr1
Here is my response https://ibb.co/nKqq8F (tried to attach it but exceeded the 
lists max size msg), that can help you as a guide. After we have some responses 
I'll share the responses with the community.

On Sat, May 20, 2017 at 2:57 PM, Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>> wrote:
Hi all, this is the form: https://goo.gl/forms/oloBgwQlLU3NGrbr1
Attached find my response, that can help you as a guide. After we have some 
responses I'll share the responses with the community.


On Sat, May 20, 2017 at 10:51 AM, Bert Verhees 
mailto:bert.verh...@rosa.nl>> wrote:

Yes, me too, good idea. Working on project, more details soon

Op za 20 mei 2017 10:04 schreef Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>>:
Great suggestions, will add a comment on that to the form so people can specify 
that in free text (trying not to make it too structured).

On Sat, May 20, 2017 at 4:14 AM, Pieter Bos 
mailto:pieter@nedap.com>> wrote:
Hello Pablo,

This sounds like a good initiative! Maybe it could be a good idea to add some 
way to distinguish ADL 1.4 and ADL/AOM 2 projects. Perhaps also the different 
RM versions?

Regards,

Pieter Bos

Op 19 mei 2017 om 18:30 heeft Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>>>
 het volgende geschreven:

Hi all,

We were discussing on other threads about the need to improve the tools, ref 
impls and frameworks we use for openEHR stuff. We are few in the community 
working on those areas, and sometimes doing duplicated work and overlapping 
solutions.

I believe if we know who is working on what, we can make a better use of our 
collective time as a community, and reuse others work, or even help on their 
projects.

Modeling tools are getting behind the specs progress, tool chain is broken and 
needs manual work to get modeling done, open implementation tech stacks are not 
complete, etc...

What if we can publish the areas we are working on, tools that we already have, 
and try to coordinate better to fix those issues and collaborate better as a 
community?


I have created a small google form to gather and share that info, it has these 
questions:

1. On which areas are you / your company working on? (modeling tools, CDRs, 
APIs, ...)
2. Is code open or planned to be open?
3. Current status (idea, planned, developing, developed, released, ...)
4. Main issues and challenges (for the community to help)
5. Available tools / solutions and where to find them


If you see there is another question that can add value to this, please let me 
know. After this is complete, I'll share the form. When we have some answers, 
I'll publish them on the wiki.

Hopefully others can this this as an opportunity to move forward on the 
modeling and dev areas to increase openEHR adoption.


Kind regards,
Pablo.

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

___
openEHR-technical mailing list
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



[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

___
openEHR-technical mailing list
openEHR-techni

RE: SNOMEDCT - correct representation

[Koray Atalag]

Hi Michael,

You can only define and manage so many ECL valuesets and assign URIs - which is 
fine. Trouble is the combinations are endless. Therefore IMHO we definitely 
need ways to embed post-coordinated terms (for defining meaning) and ECL (for 
valuesets) in terminology bindings.

Tom I like your suggestion for a terminology referencing way to include all of 
the above. I would also argue that we should be able to mix terms from 
different terminology and ontology systems as well. In computational 
physiology, where they don't have an uber-ontology like SNOMED, when defining 
semantic annotations (our terminology bindings) they can use kind of 
post-coordination (all URIs): [term1:ontologyA] [relation-may_be_defined_in 
ontology B] [term2:ontology C] etc. you'll get the idea.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of michael.law...@csiro.au
Sent: Thursday, 4 May 2017 1:05 a.m.
To: openehr-technical@lists.openehr.org
Subject: [FORGED] Re: SNOMEDCT - correct representation

I think this thread has gone a little off the rails.

There are predefined (by FHIR) URIs for value sets that are defined just as 
descendants of a single concept, or members of a reference set.

For an enumeration of concepts and/or a snomed ECL expression, then you can use 
a Fhir ValueSet and give it a URI.  ValueSets also generalise beyond just 
SNOMED (LOINC for example).

Furthermore, there are existing tools to expand them to the set of member 
concepts, you can include metadata, manage versions etc.  This is much more 
than you get just by encoding ECL in a URI.

In case anyone wants to play with ECL expressions and their evaluation you can 
go here for an interactive page:
https://ontoserver.csiro.au/shrimp/ecl.html

Also, some brief documentation and click-through examples here
https://ontoserver.csiro.au/shrimp/ecl_help.html

Regards

Michael
Sent from my iPhone

On 3 May 2017, at 9:08 pm, Diego Boscá 
mailto:yamp...@gmail.com>> wrote:
Seems like the only way right now is creating refsets and referencing them with 
standard URIs...

2017-05-03 13:02 GMT+02:00 Bert Verhees 
mailto:bert.verh...@rosa.nl>>:
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



--

[VeraTech for Health SL]

[Twitter]   [LinkedIn]  
  [Maps]  

[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 / +34 
627015023
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman parte de 
un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad 
es la de mantener el contacto con usted. Conforme a La Ley Orgánica 15/1999, 
usted puede ejercitar sus derechos de acceso, rectificación, cancelación y, en 
su caso oposición, enviando una solicitud por escrito a 
verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr

RE: SNOMEDCT - correct representation

[Koray Atalag]

Hi again,

I've been snowed under for a while and just now catching up with this...I 
reckon there was a suggestion that we do not include SNOMED codes within 
archetypes, or more specifically post-coordinated expressions, if I understand 
correctly but to define these somewhere else and then include the external URI 
instead. While this would be a good solution for well-defined expressions, 
subsets etc. I think if you think about the vast amount of potential 
expressions with almost endless permutations of terms it quickly becomes too 
complex and unmanageable. Therefore there will always need for including 
specific expressions within archetypes and templates.

I've been doing a lot of terminology bindings using various ontologies and 
terminology lately and I think we need urgently a consistent way to make these 
bindings and get the tools support it. For example when term bindings (for the 
purpose of defining real-world meaning of a node) are done at archetype level 
you end up with local at codes that refer to each binding and then it is 
possible to link one or more terms from same or different terminology systems. 
For the purpose of providing a valueset to a DV_CODED_TEXT at archetype level 
we don't have a very clear way - we keep on saying we'll put a terminology 
query but it is not really usable or useful. Tooling support is also not 
satisfactory. But when you do that at template level (e.g. define a valueset 
for a DV_TEXT by further constraining it to DV_CODED_TEXT or an existing 
DV_CODED_TEXT) it is just a list of terms, code and terminology system with 
version/release. It is not clear how we can refer to an external list defined 
by a terminology query or refset - at least I couldn't figure out. There's 
quite an inconsistency between archetype vs template defined valuesets within 
.opt - whereas they should be defined in the same way and share same semantics.

I don't know how to fix it - my guess is that this is not a commonly used 
feature so it was never a high priority for SEC group. I think it is time to 
bring loose ends together as more and more countries adopt SNOMED and there is 
clear pressure to do this.  FHIR terminology service is quite good and I think 
we should just start using it. If we need further bells and whistles it can be 
extended.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Koray Atalag
Sent: Tuesday, 2 May 2017 11:47 p.m.
To: For openEHR technical discussions
Subject: [FORGED] RE: SNOMEDCT - correct representation

Yup - that's the right URI format.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, 27 April 2017 1:01 a.m.
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: SNOMEDCT - correct representation




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"] = 
<http://snomed.info/id/163020007><http://snomed.info/id/163020007>
["id5"] = 
<http://snomed.info/id/163030003><http://snomed.info/id/163030003>
["id6"] = 
<http://snomed.info/id/163031004><http://snomed.info/id/163031004>
["id14"] = 
<http://snomed.info/id/246153002><http://snomed.info/id/246153002>
>
["openehr"] = <
["at1055"] = <http://openehr.org/id/125><http://openehr.org/id/125>
["at1056"] = <http://openehr.org/id/497><http://openehr.org/id/497>
["at1057"] = <http://openehr.org/id/146><http://openehr.org/id/146>
>
>
- 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 pr

RE: SNOMEDCT - correct representation

[Koray Atalag]

Yup - that's the right URI format.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, 27 April 2017 1:01 a.m.
To: openehr-technical@lists.openehr.org
Subject: Re: SNOMEDCT - correct representation




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

RE: UCUM code in body temperature archetype

[Koray Atalag]

Hi Ian,

In NZ we use the NZMT which is based on AMT (which is 
based on dm+d) – the tricky bit is neither of these are part of the SNOMED CT 
proper in terms of content but they do use SCTIDs and have formal IHTSDO 
namespace as national extensions. Based on the NZMT we have a 
Formulary which are all provided through 
the NZULM service. I really think is this the right way 
to go with medicines although there’s quite a bit of discomfort (among health 
informaticians / developer community) with the constraints the SNOMED CT way of 
representation brings (the 7-Boxes) and the fact that content is not harmonised 
with international edition so comparative studies can be done across different 
jurisdictions. There is also belief an SPARQL based access (at least as an 
alternative) to medicines terminology would be a better way. My 2 cents

I’d support adding the means to manage medicinal units (called units of use) at 
RM level (e.g. as a separate data type).

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Thursday, 19 May 2016 8:09 p.m.
To: For openEHR technical discussions
Subject: Re: UCUM code in body temperature archetype

Hi Thomas,

In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose 
units because the latter are expressed as SNOMED terms, and are used in 
conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to compute 
actual doses/amounts where possible.

e.g.

318421004 | Atenolol 100mg tablets |

via dm+d allows us to infer that 1 tab (in this case) = 100mg

http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004&toc=nofloat


and allows us to do maximum daily dose calculation, at least against a defined 
subset of such 'dose units'.

in other cases the dose unit strength will be defined as part of the medication 
order - we have a 'Strength' element in the medication order archetype for just 
such a purpose.

I don't think we need to be able to define the unit strength as part of the 
quantity datatype.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 May 2016 at 08:24, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

Hi Gerard,

they actually could be, but whenever this discussion comes up, no-one proposes 
it. I'm not sure if I would either, because these arbitrary units are still not 
computable in general, but 'dose units' can be made computable but only with 
some extra data fields, i.e. you need both the quantity of dose in 1 
tablet/capsule etc, and also number of tablet/capsule etc. So the structural 
model is different anyway.

I think the other problem with using UCUM arbitrary units is that people / orgs 
want to control the names of medicinal delivery products ('tablet' etc) in a 
terminology, which is reasonable, but doesn't fit so well with UCUM.

- thomas

On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
Thomas,

All are Units of a different kind.

SI defines: Units of Measure, and Units of Quantity in the scientific domain.

There are also Units of Time: minute, hour, etc.

When I think of tablets, capsule, etc. we will call these Units of Medicinal 
Product Dose.
Isn’t in UCUM this an example of Arbitrary Units?
3.2

ARBITRARY UNITS


§24 arbitrary units   ■1 Arbitrary or procedure defined units are units 
whose meaning entirely depends on the measurement procedure (assay). These 
units have no general meaning in relation with any other unit in the SI. 
Therefore those arbitrary semantic entities are called arbitrary units, as 
opposed to proper units. The set of arbitrary units is denoted A, where A∩ U = 
{}.   ■2 An arbitrary unit has no further definition in the semantic framework 
of The Unified Code for Units of Measure  ■3 Arbitrary units are not “of any 
specific dimension” and are not “commensurable with” any other unit.

Until version 1.6 The Unified Code for Units of Measure has dealt with 
arbitrary units as dimensionless, but as an effect the semantics of The Unified 
Code for Units of Measure made all arbitrary units commensurable. Since version 
1.7 of The Unified Code for Units of Measure it is no longer possible to 
convert or compare arbitrary units with any other arbitrary unit.

§25 operations on arbitrary units   ■1 Any term involving arbitrary units, 
is itself an arbitrary unit and is not comparable with any other arbitrary unit 
or term.

§26 definition of arbitrary units   ■1 Arbitrary units are marked in the 
definition tables for unit

RE: SNOMED

[Koray Atalag]

Hi,

Just to add some historical context - SNOMED evolved from a terminology 
designed to be a Reference Terminology (as opposed to Interface/Clinical 
Terminology) at a time where ontologies were non existent or very primitive 
(<90s). Hence the poor formal ontological commitment as of today - in the past 
10-15 years they have transformed the content to serve a different purpose - to 
act as Interface/Clinical terminology and most flaws are related to this 
baggage. That said they are actively working to align with current ontology 
good practices; e.g. I learned there's work underway to restructure anatomical 
sites as per FMA which is a good step forward. I heard they are also looking at 
other content areas to align with OBO etc.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Saturday, 30 April 2016 2:43 a.m.
To: openehr-technical@lists.openehr.org
Subject: Re: SNOMED


Hi Bert
Erik and Ian partly answered this, but it is always worth remembering that 
SNOMED CT, if based on proper ontological principles, contains assertions that 
represent entities in the real world. This means taxonomy (IS-A) and 
properties, qualities, possible relationships and so on (see BFO2 

 for a modern top-level ontology providing these ideas). These are properties, 
qualities and relationships of real things in the real world, i.e. actual 
hearts, cardiac arrests, disease types and so on.

The openEHR RM and derivative archetypes are built to represent information 
'about' these real things. The relationship is often written as 'is-about'. 
There are important differences to be aware of:

  *   what information is written 'about' many things can sometimes resemble a 
description of the thing itself, e.g. parts of a colonoscopy report tend to 
follow anatomical structure of colon and things found in it;
  *   sometimes it relates to a surrogate phenomenon, e.g. an archetype for 
heart rate that actually records pulse; a great deal of clinical observation is 
of surrogates e.g. state of skin, palpation, heart sounds, asking about pain, 
blood glucose etc, but they are actually about something else;
  *   what gets recorded can be what is cheap and painless to record; consider 
that we don't do an echocardiogram every time you want simple BP or heart rate.
  *   what gets recorded about X can be culturally determined; different in 
other ways from 'how X really is' in nature.
  *   most important: most clinical data recordings don't replicate 'textbook' 
relationships found in an ontology, e.g. the fact that there are 5 heart 
Korotkoff sounds at different phases of the cardiac cycle will never be written 
down by a physician, neither will the fact that systolic BP is-a pressure of 
blood in a vessel is-a pressure of fluid in a vessel etc. So if we were to 
generate an information structure from part of an ontology representing the 
heart / CV system, it would generate numerous useless data points and 
relationships on the information side.
How well or how much SNOMED CT follows underlying ontologies like BFO2 or 
Biotoplite or whatever is another question. I am not up to date on the 
progress, but I am fairly sure that most of SNOMED has not been validated 
against these kinds of ontologies. The waters are muddied further by the 
attempts to represent informational, timing and context-related entities in 
SNOMED CT.

Thus, my view is that: in principle, generating information structures straight 
from an ontology (even a perfectly built one) will simply never work, for the 
reasons in the list above; in practice, what you would get from SNOMED CT, 
given its imperfect adherence to ontology would be even harder to understand or 
use.

- thomas
On 29/04/2016 07: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 

RE: CAMSS assessment of openEHR

[Koray Atalag]

Ditto - the main problem is that while we appreciate the important and 
complementary roles of clinical terminology, information models and health 
information exchange specifications (which should normally be created as 
downstream artefacts from the broader whole of 'EHR' content models for the 
particular use case that they address) the governments and regional authorities 
don't seem to get this. Perhaps some get it but find difficult to justify 
because this is somewhat seen as a rather academic view. I guess it is our 
responsibility to continue to work on to educate and more importantly create 
some hard evidence so that they feel more confident in making such decisions. 
We should also accept the fact that, historically, we have not done a very good 
job of creating such evidence and be very open and completely transparent to 
drive that confidence - however I want to believe that things have changed for 
the better in recent years.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Erik Sundvall
Sent: Sunday, 10 April 2016 6:12 p.m.
To: For openEHR technical discussions
Subject: SV: CAMSS assessment of openEHR

Hi!

Sadly I don't think it is very often you see goverment initiatives etc actually 
looking for standardisation at the "clinical" layer in the sense of 
documentation models that openEHR archetyping covers.

They often look for a technical standard (capable of defining messages and 
code-value-paitinig etc) plus some set of terminology systems. They often 
believe that such a combination will solve the interoperability problems 
efficiently.

I do not think they usually consider the quality of the clinical content or the 
processes, ecosystems, communities and update mechanisms used to produce those 
message defintitions or documentation patterns. Neither do they consider how 
well message definitions match what clinicians actually want to enter in EHR 
systems and later query for. (They probably think that is the job of each EHR 
vendor and that mapping-wizards will do the magic of converting from EHR 
entries to messages and back, as usual.)

Sometimes this applies: 
https://coiera.com/2015/05/12/a-modest-e-health-proposal-to-government/ I don't 
know if that is valid for the Norwegian situation now or not.

Please share good examples of national initiatives actually assesing the 
clinical qualities of different approaches. That could be userful and 
interesting to look at.
Best regards,
Erik Sundvall

Från: openEHR-technical [openehr-technical-boun...@lists.openehr.org] för Ian 
McNicoll [i...@freshehr.com]
Skickat: den 9 april 2016 09:38
Till: For openEHR technical discussions
Ämne: Re: CAMSS assessment of openEHR
Hi Silje,

As far as I can see the specification process is fully documented at 
http://openehr.org/programs/specification/ but it is a technical specification 
and therefore highly detailed.

but in terms of ' standards' development, which I thought was the initial 
remit, surely the clinical modelling layer is just as significant (possibly 
more so)?

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 6 April 2016 at 13:20, Bakke, Silje Ljosland 
mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:
I think they're only interested in the specs, not archetypes. And I think the 
point is that it should be possible to learn how the processes work without 
being shown. :)

Regards,
Silje

Fra: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org]
 På vegne av Ian McNicoll
Sendt: 5. april 2016 23:04
Til: For openEHR technical discussions
Emne: Re: CAMSS assessment of openEHR

Just to add. I sense that there is a real difficulty for those involved in the 
reviews in understanding anything other than traditional ISO/CEN type 
standards/specification processes.

Do we have an opportunity to show them how an archetype review process works, 
or to show how the specifications review process works?

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 5 April 2016 at 23:01, Ian McNicoll 
mailto:i...@freshehr.com>> wrote:
Hi Silje,

Thomas and Erik 

RE: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

[Koray Atalag]

That's great call - many thanks

Cheers,

-koray


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Tuesday, 15 March 2016 1:55 a.m.
To: For openEHR technical discussions
Subject: Re: Socio-technical challenges when the openEHR approach is put to use 
in Norwegian hospitals

Many thanks Jan (and of course to the author),

Clearly this paper has aroused considerable interest/debate. It is good that 
the whole community can see it and and discuss in details.

Ian


Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR 
Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On 14 March 2016 at 06:47, jan@home  wrote:
> I asked to author to send the accepted version of the manuscript to the 
> mailing list. She is not on the list, but I got permission to so so. Please 
> see attached.
>
> Jan Talmon
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.org

___
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-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: openEHR-Based PhD Thesis Successfully Defended

[Koray Atalag]

Bi congrats Nadim - FYI your 
thesis is already 
accessible from openEHR Research 
Library on Zotero.

Cheers,

-koray

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Nadim Anani
Sent: Thursday, 10 March 2016 4:21 a.m.
To: For openEHR clinical discussions (openehr-clini...@lists.openehr.org); For 
openEHR implementation discussions (openehr-implement...@lists.openehr.org); 
For openEHR technical discussions (openehr-technical@lists.openehr.org)
Subject: openEHR-Based PhD Thesis Successfully Defended

Dear all,

Following Diego's email, I would like to also announce my successfully defended 
PhD thesis (on the 12th of February 2016): 
https://openarchive.ki.se/xmlui/handle/10616/44956

This thesis explores ways of how openEHR can come into evidence-based practice 
via clinical practice guidelines. It covers the following in essence, amongst 
some other things:


-It proposes a method for representing guidelines based on CARE_ENTRY 
types, the so-called Care Entry-Network Model.


-It gives one of the first ever detailed accounts of how the 
openEHR-based Guideline Definition Language (GDL) works.



-It conducts the first ever GDL-based study using patient data from a 
registry.



-The latter effort, using the Safe Implementation of Treatments in 
Stroke (SITS) international patient data registry, leads to real clinical 
findings.



Sincerely,
Nadim




Nadim Anani, PhD
Centrum för hälsoinformatik / Health Informatics Centre (HIC)
LIME
Karolinska Institutet
SE-17177 Stockholm, Sweden

Tel. +46-8-524-83607
Email: nadim.an...@ki.se
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Any work on PHR?

[Koray Atalag]

Hi, are you aware of any openEHR based personal health record project?

The aim would be to capture wellness type of information integrated with  
recent wearable/smart phone based sensor data.
Preferably open source.

Cheers,

-koray

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

RE: Strange use of 'offset' as a settable RM attribute

[Koray Atalag]

Thanks Tom - this could finally make me an ADL Workbench user ;)

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, 18 February 2016 12:01 a.m.
To: openehr-technical@lists.openehr.org
Subject: Re: Strange use of 'offset' as a settable RM attribute


Using the rules could be a useful approach. One thing we decided in the SEC 
meeting last week was to rework the 'rules' part of ADL as a small core model 
in the BASE component and then re-use that back into ADL2 and also GDL. This 
will result in a new small BASE/Rules specification and the ADL2 and GDL models 
of rules will then be rewritten to be based on this. I'm working on the 
BASE/Rules component right now, and will put it up very soon in draft (status = 
DEVELOPMENT) form, so anyone can have a go at working on it.

I've managed to clean up some of the semantics around functions and variables 
etc, so I think the initial version will be reasonable. There are others who 
know this area better than I do, so I encourage them to have a look and if 
interested to contribute to improving the models, get involved.

BTW the ADL workbench does display rules:

[cid:image001.png@01D16A35.AD988580]

- thomas
On 17/02/2016 09:08, Diego Boscá wrote:
Both ADL1.4 and ADL2 support assertions (rules in ADL2)

http://www.openehr.org/releases/AM/latest/docs/ADL1.4/ADL1.4.html#_assertions

http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_rules_2
The bad news about that is that I believe that no ADL editor supports them yet 
(as far as I know). We are now researching in this area and will have some 
results in the near future.


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

RE: [FORGED] Re: Strange use of 'offset' as a settable RM attribute

[Koray Atalag]

l: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[Image removed by sender.]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 12 February 2016 at 04:29, Koray Atalag 
mailto:k.ata...@auckland.ac.nz>> wrote:
Hi,

We noted it is possible to set values from AE/TD to a RM attribute named 
“offset”
In the 
specs<http://www.openehr.org/releases/RM/Release-1.0.3/docs/data_structures/data_structures.html#_event_class>
 (looked at >1.0.1) it is not a regular attribute but a function which returns 
a computed value using diff HISTORY.origin and EVENT.time
Note that this diff can also be a negative value – which doesn’t seem to be 
supported by AE/TD or in instance data

An example ADL:

POINT_EVENT[at0002] occurrences matches {0..*} matches {-- Any event
   offset matches {
  DV_DURATION matches {
 value matches {|PT0.125S|}
  }
   }

Isn’t this weird?
I would expect this to return a value if a valid ISO8601 time has been entered 
for both HISTORY.origin and EVENT.time but not set as an attribute directly.

Cheers,

-koray


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

RE: Strange use of 'offset' as a settable RM attribute

[Koray Atalag]

Thanks Heath,

Setting a value constraint makes sense - do you allow negative offset? We have 
some time series observation data where offset is negative. In practice it 
doesn't make much sense but in reality it exists.

I can also imagine the sort of problems you may be facing - does this mean we 
should perhaps define priority/preference over EVENT.time vs. EVENT.offset. 
Obviously we got a problem when both exists.


Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Heath Frankel
Sent: Monday, 15 February 2016 7:53 p.m.
To: For openEHR technical discussions
Subject: Re: Strange use of 'offset' as a settable RM attribute

Does our opt validator validate a data instance against this? Yes.
It causes all sorts of problems in scenarios like apgar when event times are 
real rather than derived from the origin and this constraint.
Regards

Heath



On Sun, Feb 14, 2016 at 11:34 AM -0800, "Ian McNicoll" 
mailto:i...@freshehr.com>> wrote:
Thanks Heath,

That makes sense. Does OceanEHR validate the constraint?

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 14 February 2016 at 19:02, Heath Frankel 
mailto:heath.fran...@oceaninformatics.com>> 
wrote:
Hi Koray,
This is a constraint on the value that origin function returns rather than 
indicating it is a settable attribute. This was how Sam defined the events on 
an apgar score, 1 min, 5 min, etc.
Regards

Heath

_
From: Ian McNicoll mailto:i...@freshehr.com>>
Sent: Sunday, February 14, 2016 5:10 AM
Subject: Re: Strange use of 'offset' as a settable RM attribute
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>


Hi Koray,

I agree - can you create a JIRA PR at ...

https://openehr.atlassian.net/projects/AEPR/issues/AEPR-45?filter=allopenissues

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 12 February 2016 at 04:29, Koray Atalag 
mailto:k.ata...@auckland.ac.nz>> wrote:
Hi,

We noted it is possible to set values from AE/TD to a RM attribute named 
"offset"
In the 
specs<http://www.openehr.org/releases/RM/Release-1.0.3/docs/data_structures/data_structures.html#_event_class>
 (looked at >1.0.1) it is not a regular attribute but a function which returns 
a computed value using diff HISTORY.origin and EVENT.time
Note that this diff can also be a negative value - which doesn't seem to be 
supported by AE/TD or in instance data

An example ADL:

POINT_EVENT[at0002] occurrences matches {0..*} matches {-- Any event
   offset matches {
  DV_DURATION matches {
 value matches {|PT0.125S|}
  }
   }

Isn't this weird?
I would expect this to return a value if a valid ISO8601 time has been entered 
for both HISTORY.origin and EVENT.time but not set as an attribute directly.

Cheers,

-koray


___
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

Strange use of 'offset' as a settable RM attribute

[Koray Atalag]

Hi,

We noted it is possible to set values from AE/TD to a RM attribute named 
"offset"
In the 
specs
 (looked at >1.0.1) it is not a regular attribute but a function which returns 
a computed value using diff HISTORY.origin and EVENT.time
Note that this diff can also be a negative value - which doesn't seem to be 
supported by AE/TD or in instance data

An example ADL:

POINT_EVENT[at0002] occurrences matches {0..*} matches {-- Any event
   offset matches {
  DV_DURATION matches {
 value matches {|PT0.125S|}
  }
   }

Isn't this weird?
I would expect this to return a value if a valid ISO8601 time has been entered 
for both HISTORY.origin and EVENT.time but not set as an attribute directly.

Cheers,

-koray

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

RE: [FORGED] A report of openEHR events in Japan

[Koray Atalag]

Big congrats to you Shinji and others who put this fantastic event together.

Cheers,

-koray


-Original Message-
From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Shinji KOBAYASHI
Sent: Thursday, 4 February 2016 3:47 a.m.
To: For openEHR clinical discussions; For openEHR technical discussions
Subject: [FORGED] A report of openEHR events in Japan

Hi all,

We, openEHR Japan had two events in the last January.
I wrote  a report of the events of them, and please take a look at this.

http://openehr.jp/documents/8

We appreciate the participants and kind supports from Drs Hugh and Heather 
Leslie from Australia, Dr Lu from China, localisation team, management board, 
and all the openEHR coleagues.

Shinji KOBAYASHI

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

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

RE: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

[Koray Atalag]

And I just noted, Ocean's Archetype Editor does allow for microseconds but when 
you select and save it cannot save it. So it is a bug.

It looks definitely a deficiency of the openEHR RM.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Tuesday, 2 February 2016 11:18 p.m.
To: For openEHR technical discussions
Subject: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

On 02-02-16 11:07, Koray Atalag wrote:
Hi Bert, I was saying ISO8601 do support this - it is openEHR that constrains 
to milliseconds.

You are right, you do say that. I don't know if your code supports this, 
because the ISO-time-string will be converted to a Time-class and must have the 
same value when converted back.

The Java 8 LocalTime class supports until 9 decimals.




In my case it is action potential measurement from myocytes

Sounds interesting, I asked because it is rare to measure microseconds in 
medical applications.

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

RE: [FORGED] Re: Representing microseconds in DateTime

[Koray Atalag]

Hi Bert, I was saying ISO8601 do support this - it is openEHR that constrains 
to milliseconds.

In my case it is action potential measurement from myocytes

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Tuesday, 2 February 2016 10:59 p.m.
To: openehr-technical@lists.openehr.org
Subject: [FORGED] Re: Representing microseconds in DateTime

Just for the record, which medical requirement makes measuring micro-seconds 
necessary?

By the way, ISO allows one or more digits to represent a decimal fraction of a 
second.

I don't have the original standard at hand, but Wikipedia says:
https://en.wikipedia.org/wiki/ISO_8601
There is no limit on the number of decimal places for the decimal fraction.

Bert




On 02-02-16 10:51, Koray Atalag wrote:
Hi,

I have a requirement to capture timeseries data which happens at 250 
microseconds - that is 0.000250 seconds.
While many programming languages, and the ISO8601 spec, supports this  openEHR 
RM<http://www.openehr.org/releases/RM/latest/docs/support/support.html#_iso8601_time_class>
 seems to be constrained to milliseconds:
hh:mm:ss[,sss][Z | ±hh[mm]]

Any particular reason we dump microseconds? If not can we add this capability - 
I think it won't break any existing code (I hope!)

Cheers,

-koray





___

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

Representing microseconds in DateTime

[Koray Atalag]

Hi,

I have a requirement to capture timeseries data which happens at 250 
microseconds - that is 0.000250 seconds.
While many programming languages, and the ISO8601 spec, supports this  openEHR 
RM
 seems to be constrained to milliseconds:
hh:mm:ss[,sss][Z | ±hh[mm]]

Any particular reason we dump microseconds? If not can we add this capability - 
I think it won't break any existing code (I hope!)

Cheers,

-koray

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

RE: Representing microseconds in DateTime

[Koray Atalag]

Hi Tom, I've been experimenting to save to Ehrscape and it seems the 
implementation is truncating (not rounding off) beyond 3digits. So whatever I 
include after 3rd digit is not saved.

"encounter/body_weight:0/any_event:1/time": "2016-02-01T01:04:09.907123Z" > I 
get: "encounter/body_weight:0/any_event:1/time": "2016-02-01T01:04:09.907Z"

To be honest the spec as it reads now seems ambiguous with 3 digits.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Wednesday, 3 February 2016 12:21 a.m.
To: openehr-technical@lists.openehr.org
Subject: Re: Representing microseconds in DateTime


I don't think there is any assumption that [,sss] means there are no 
microseconds. The field is just called 'fractional_second' and it's a Real 
(i.e. a float). We just used 'sss' as an arbitrary indicator of fractional 
seconds (how many 's' do you want ;-)

- thomas
On 02/02/2016 09:51, Koray Atalag wrote:
Hi,

I have a requirement to capture timeseries data which happens at 250 
microseconds - that is 0.000250 seconds.
While many programming languages, and the ISO8601 spec, supports this  openEHR 
RM<http://www.openehr.org/releases/RM/latest/docs/support/support.html#_iso8601_time_class>
 seems to be constrained to milliseconds:
hh:mm:ss[,sss][Z | ±hh[mm]]

Any particular reason we dump microseconds? If not can we add this capability - 
I think it won't break any existing code (I hope!)

Cheers,


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

RE: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

[Koray Atalag]

Hi Bert, yes it is an extreme case - most clinical measurements will not go in 
this range.

Python's DateTime library <https://docs.python.org/2/library/datetime.html>  
(which I'm using at the moment) supports 6 digits after decimal point which 
gives resolution of 1 microseconds.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Tuesday, 2 February 2016 11:18 p.m.
To: For openEHR technical discussions
Subject: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

On 02-02-16 11:07, Koray Atalag wrote:
Hi Bert, I was saying ISO8601 do support this - it is openEHR that constrains 
to milliseconds.

You are right, you do say that. I don't know if your code supports this, 
because the ISO-time-string will be converted to a Time-class and must have the 
same value when converted back.

The Java 8 LocalTime class supports until 9 decimals.




In my case it is action potential measurement from myocytes

Sounds interesting, I asked because it is rare to measure microseconds in 
medical applications.

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

RE: New EHRServer v0.5 and roadmap

[Koray Atalag]

Hi Pablo, the guide is very readable and to the point. Well done. I'll 
definitely play around in the next few days.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Friday, 15 January 2016 4:12 p.m.
To: openeh technical
Subject: RE: New EHRServer v0.5 and roadmap

@all the guide is ready!

http://cabolabs.com/software_resources/EHRServer_v0.5.pdf

Please let me know if you find any errors or if any part needs clarifications, 
thanks!

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: pazospa...@hotmail.com
To: 
openehr-technical@lists.openehr.org
Subject: RE: New EHRServer v0.5 and roadmap
Date: Thu, 14 Jan 2016 22:56:13 -0300
Thanks Seref, this is really kind of you. I agree that we need more open source 
implementation out there and I hope my little project help others to develop 
their own.

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Date: Thu, 14 Jan 2016 20:30:10 +
Subject: Re: New EHRServer v0.5 and roadmap
From: 
serefari...@kurumsalteknoloji.com
To: 
openehr-technical@lists.openehr.org
Hi Pablo,
Just wanted to say well done. I have not had the chance to look at your work, 
mainly because work and studies forced me to take a step back from open source 
efforts, but it is great to see the continuous progress you're making.

It is very important that there is an open source implementation of openEHR out 
there that is actively developed. Don't worry about the performance either. If 
someone wants to use it and they think it is not fast, they should pay you to 
make it faster.

I hope it gets adopted and you keep working on it.

All the best
Seref


On Thu, Jan 14, 2016 at 5:42 AM, pablo pazos 
mailto:pazospa...@hotmail.com>> wrote:
Hi all!

I'm very excited to share the good news with all my openEHR friends here.

We have released EHRServer v0.5! This version is what we could call "feature 
complete", so it includes all the minimum features of a real openEHR server, 
the latest ones related to securing the API, and before that, supporting 
multi-tenancy.

I'll release user documentation and a full REST API documentation in the next 
couple of days, and will record a demo in English on YouTube via Hangout. I 
made a demo in Spanish not so long ago: 
https://www.youtube.com/watch?v=84YiNfkLGMA

Also, we have a staging server to test the EHRServer*, you are very welcome to 
try it and give us some feedback to continue improving the tool: 
https://cabolabs-ehrserver.rhcloud.com/ehr

* You can create an account and start using it.

Note: the server is not so fast, but is usable.


I'm working hard on v0.6 right now, hopefully we'll have a release before 
February. This version will include fixes to the UI, REST API, and security 
checks, more testing, testable REST API docs, among other things. The focus 
will be on robustness, security, and consistency more than adding new features. 
We can call the EHRServer v0.6 a "production ready" system.

I started to meet with some friends and colleagues interested on using the 
EHRServer as an open-source openEHR backend. My next focus will be on building 
pilot projects with some companies, to let them try the EHRServer and see if it 
fits their needs and gathering information to improve it. If anyone is 
interested, please give me a ring or ping my by email!


--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

___
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-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
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: EHRServer v0.4 released

[Koray Atalag]

Well done Pablo – a PhD student of mine and also a colleague will be playing 
with it shortly. Will definitely feed back!
Keep up the great work ☺

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pazospa...@hotmail.com
Sent: Sunday, 29 November 2015 6:36 a.m.
To: openehr-technical@lists.openehr.org; For openEHR implementation ...
Subject: EHRServer v0.4 released


Dear friends, we have released the new version of the EHRServer 
https://github.com/ppazos/cabolabs-ehrserver



I'll update the docs soon and deploy the new version on our staging server for 
anyone who wants to test it.



Feedback is very welcome!



Cheers,

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

Maven Archetype – About

[Koray Atalag]

http://maven.apache.org/archetype/

Interesting definition (though not related to our models)

Cheers,

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

RE: [FORGED] Nation wide EHR project by openEHR/ISO13606 got fund in Japan.

[Koray Atalag]

Dear Shinji, big congrats to you…Perseverance and hard work wins finally.

Let us know how best to support you (other than a virtual toast ;)

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Shinji KOBAYASHI
Sent: Friday, 9 October 2015 1:20 a.m.
To: For openEHR clinical discussions; For openEHR technical discussions; For 
openEHR implementation discussions
Subject: [FORGED] Nation wide EHR project by openEHR/ISO13606 got fund in Japan.

Dear openEHR colleagues,
We are happy to announce that Japan Medical Network Association(JMNA) was 
designated to implement nation wide EHR with openEHR/ISO 13606 information 
models in competitive bid by Japan agency for medical research and development.
To the next March, JMNA will implement EHR system with vendors in Japan by this 
budget, about 5 million USD.
We, openEHR Japan, will contribute to make models for this EHR project.
I wish this achievement would make happy waves to your countries.
Best Regards,
Shinji KOBAYASHI
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Advantage of ISO

[Koray Atalag]

I think Silje’s explanation is crystal clear on this matter – so what exactly 
your problem is Gerard with openEHR? Can you give a concrete example where 
other SDOs you mention are better placed wrt to freedom?

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Thursday, 3 September 2015 10:18 a.m.
To: For openEHR technical discussions
Subject: RE: Advantage of ISO

No. The Creative Commons licenses guarantees the free (as in beer) use and 
distribution of the specifications and the free (as in speech) use, 
distribution and improvement of the artifacts. This is what makes openEHR open 
and not proprietary. The organisation of the body holding the copyright and 
trademark is completely irrelevant.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of "Gerard Freriks (privé)"
Sent: Thursday, September 03, 2015 9:11 AM
To: For openEHR technical discussions
Subject: Re: Advantage of ISO

I think that it is NOT a misuse.

openEHR has one owner.
CEN and ISO have members (countries) that are, all together, the owner.

This a huge difference, don’t you think?

Gerard


On Sep 3, 2015, at 8:48 AM, Bakke, Silje Ljosland 
mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:

This is a misuse of the dictionary definition. Using your interpretation, all 
free/open projects are proprietary unless both IP and trademarks are made 
Public Domain. Linus Torvalds is the IP copyright holder and trademark owner of 
Linux, but because it’s released under a free license, it’s not proprietary 
software. The same goes for the openEHR Foundation and openEHR 
specs/artifacts/software.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway


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

RE: Archetype editor, CKM and v0 & v1

[Koray Atalag]

+1

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Friday, 7 August 2015 8:07 p.m.
To: For openEHR technical discussions
Subject: RE: Archetype editor, CKM and v0 & v1

I'm assuming there's no reaction to this because everyone is still enjoying 
their well-earned holidays. :)

But this is a serious issue, which leads to only people "in the know" being 
able to download updated tools and create and edit archetypes and templates 
which conform to the newest patterns. Precisely what we'd like to avoid, isn't 
it?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Tuesday, August 04, 2015 10:45 AM
To: For openEHR technical discussions
Subject: RE: Archetype editor, CKM and v0 & v1

On a related note; the openehr.org website still advertises Archetype Editor 
v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. Especially now after 
the v1 -> v0 change, the newest builds should be linked from the web site.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, July 23, 2015 1:07 AM
To: 
openehr-technical@lists.openehr.org
Subject: Re: Archetype editor, CKM and v0 & v1


good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything else, it 
must start with a dot. Somewhat safer perhaps.

- thomas

On 22/07/2015 23:34, Peter Gummer wrote:
Hi Ian,

The + is redundant here, since it's just saying that there has to be one or 
more digits after the 'v'. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the 'v', followed by anything at 
all. This amounts to the same, since any extra digits qualify as "anything at 
all".

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
mailto:i...@freshehr.com>> wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

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

--
[Ocean Informatics]

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHR
Honorary Research Fellow, UCL
Chartered IT Professional Fellow, BCS
Health IT blog

[View Thomas Beale's profile on LinkedIn]


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

RE: CKM for training purposes

[Koray Atalag]

+1 pls

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Heather Leslie
Sent: Monday, 20 July 2015 8:14 p.m.
To: For openEHR implementation discussions; For openEHR implementation 
discussions; For openEHR technical discussions
Subject: CKM for training purposes

Hi everyone,

I'm seeking expressions of interest by groups who are interested in 
participating in an instance of CKM for the purposes of training in openEHR 
governance.

It is intended to have the first iteration of the training CKM up and running 
in time for Medinfo, which is only 4 weeks away. Rather ambitious perhaps, and 
this will only be possible if it is viable from the point of view of demand 
from the openEHR community and some commitment to contribute a modest amount 
towards the running/maintenance/adaptation costs for education purposes. Over 
time we could potentially add functionality that will allow lecturers/teachers 
to manage a subdomain per class, which could be cleared and reset at the end of 
each course to provide a clean starting point for the next group etc. I have 
already had some great ideas suggested that would enable lecturers to run 
multiple courses in parallel and identify participation from individual class 
members etc.

Please email me directly on 
heather.les...@oceaninformatics.com 
and we can start more detailed discussions with all interested parties and 
determine if this idea is of interest and potentially viable.

Kind regards

Heather

Dr Heather Leslie
MBBS FRACGP FACHI
Consulting  Lead, Ocean Informatics
Clinical Programme Lead, openEHR Foundation
Phone -  +61 418 966 670
Skype - heatherleslie
Twitter - @omowizard

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

RE: openEHR @ StackExchange

[Koray Atalag]

One needs at least 1500 reputations to introduce a new tag (obviously openEHR 
doesn't exist yet).


Cheers,

-koray

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Monday, 25 May 2015 11:41 p.m.
To: openehr-technical@lists.openehr.org; For openEHR clinical discussions
Subject: Re: openEHR @ StackExchange

On 25/05/2015 12:16, Diego Boscá wrote:
> I would assume it can be both: a question could be just about specs 
> (just the "openEHR" tag) or about any specific implementation (e.g.
> "openEHR" and "java")
>

yep - that's how I think it would work.

- thomas

___
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-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SNOMED-CT postcoordination support in ADL

[Koray Atalag]

Hi Diego,



We?re intending to use the IHTSDO syntax (or the idea) for semantic annotation 
of computational physiology models - using other domain specific languages like 
CellML, 
FieldML, SBML etc. There are 
semantic tools like SemGen or 
openCOR which support linking model items to external 
terminology/ontology similar to Archetypes. The idea is to couple clinical data 
and related physiological models to create personalised/predictive decision 
support tools using shared knowledge resources and I think this syntax has a 
great merit.



Cheers,



-koray





-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Diego Bosc?
Sent: Tuesday, 28 April 2015 8:08 p.m.
To: For openEHR implementation discussions
Cc: openeh technical
Subject: Re: SNOMED-CT postcoordination support in ADL



Hello Luis,



I think having available a terminology service is some kind of a prerequisite 
(which I don't agree with). I think openEHR should probably assume the IHTSDO 
postcoordination syntax for these cases. It would be interesting to know if 
someone has used or is planning to use this syntax for other terminologies.



2015-04-27 13:49 GMT+02:00 Luis Marco mailto:luismarco 
at gmail.com>>:

> Hi,

>

> I am trying to annotate a set of archetypes with SNOMED-CT. I have

> noticed that in the archetype editor, when I introduce a

> postcoordinated expressions, the editor deletes the bars and creates a

> continuous alphanumeric string. Do you know if postcoordinated

> expressions can be set in the ontology section of the archetype? What

> are current approaches to overcome this?

>

> A solution could be to insert an id representing the postcoordinated

> expression and resolve it in my terminology server. However, this

> would hide knowledge to other implementations based on that archetype

> outside the domain of my server.

>

>

>

> Example: Let?s assume (without caring about the correctness of it)

> that we had an archetype for the concept ?Laparoscopic appendectomy?

> and we annotate

> at000 with (80146002|Appendectomy|:424226004|Using

> device|=86174004|Laparoscope|).

>

> The result in the ADL is: ["at"] =

> <[SNOMED-CT::80146002Appendectomy424226004Usingdevice86174004Laparosco

> pe]>

>

>

>  Thanks,

>

> Luis

>

>

> ___

> openEHR-implementers mailing list

> openEHR-implementers at lists.openehr.org lists.openehr.org>

> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.o

> penehr.org



___

openEHR-technical mailing list

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: 

OpenEHR Information Design Inquiry

[Koray Atalag]

Hi Sam,

I?ve just entered a new openEHR project we have recently deployed  ? the 
Gestational Diabetes Registry underpinned by OceanEHR Platform.

Cheers,

-koray

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Samuel Frade
Sent: Thursday, 18 December 2014 3:22 a.m.
To: For openEHR implementation discussions
Cc: For openEHR technical discussions; For openEHR clinical discussions
Subject: OpenEHR Information Design Inquiry

Greetings,


We (see below for details) are collecting information about projects that 
implement openEHR based interfaces or forms, in order to write an article about 
information design in the openEHR standard elements.

Considering that your company/Institution has been developing openEHR based 
solutions, we would like you to participate in our study by answering this 
small form:

https://docs.google.com/forms/d/1OTZ4usYNIn5xpX-5ZHdMYH9eLh0B31cBeGkqwP5X6X8/viewform


In case you do not feel comfortable giving an answer to certain questions 
please leave those fields blank.

This form was started by a Msc student, but we weren't able to have enough 
answers, considering a previous inquiry on databases, so we are continuing his 
work. The following Companies/Institutions already answered our form:
Company / Institution

Application / Product / Project

Infinnity Solutions

InfinniPlatform/Medic+

Universitat Polit?cnica de Val?ncia

EHRflex

eWEAVE AB

eWEAVE Core

Marand

Think!Med Clinical

University of Auckland

GastrOS

EHR research unit, Kyoto University

rDolphin

Extensia

RecordPoint

HANDIHealth

MedsRecDIY

Acronym Software

Meddyg RIS / PACS

Ocean Informatics

Multiprac

Cambio

CDS, (Clinical Decision Support) Applications

ATOS

yourEHRM

Universidad Politecnica Valencia (UPV) & HelmholtzCentrum M?nchen

EHRFlex


Thanks in advance for taking the time to answer our questions.

We look forward to your response.

Ricardo Correia,S?rgio Cruz, Samuel Frade (CINTESIS/ Universidade do Porto/ 
Portugal)
Koray Atalag(National Institute for Health Innovation/ University of Auckland/ 
New Zealand)
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141219/083f2466/attachment.html>

Problem-oriented records and querying by problem

[Koray Atalag]

Hi Karsten,

I agree about episodicity not being particularly an issue with problem 
orientation.
Re randomness I couldn't find the best expression I guess...What I was 
referring to is the fact that the information captured by today's systems can 
be quite diverse and that stems not from the differences about data entry, 
coding etc. but more to do with human factors such as the care setting, 
qualifications and interest of the health professional capturing information, 
business rules of the organisation, organisational culture and sometimes pure 
chance. So if the patient has seen been seen by a nurse, a GP, community 
worker, specialist etc. they may all have own views of the problems and their 
relationships to goals and actions etc. and eventually any causality type links 
to observations.

I think the EHR specification and its implementation should provide firm hooks 
in the data collected to be able to generate different kinds of Problem 
Oriented Views. I assume this is one solid reason to incorporate some clinical 
semantics into RM as openEHR does.

Cheers,

-koray

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Karsten Hilbert
Sent: Wednesday, 26 November 2014 11:13 p.m.
To: openehr-technical at lists.openehr.org
Subject: Re: Problem-oriented records and querying by problem

On Wed, Nov 26, 2014 at 08:52:28AM +0000, Koray Atalag wrote:

> Another point is, although I haven't been practicing Medicine for too 
> long now, I know the links between problems vs goals vs actions do not 
> play nicely at all times - indeed for most of the time. They can be 
> subjective and quite error prone. Therefore I don't think 'natural 
> order' (as in DMBS) of an EHR cannot be of POMR type - it has to 
> follow real
> life: randomness and episodicity.

Problem orientation is -- of course -- a best-effort approach.

An EHR which "forces" problem orientation facilitates good care by making 
clinicians think about what things really mean.

What is meant by "randomness" ?

"Episodicity" does not at all run counter to problem orientation.

Karsten Hilbert
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

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

__ Information from ESET NOD32 Antivirus, version of virus signature 
database 10783 (20141126) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Problem-oriented records and querying by problem

[Koray Atalag]

Sorry I meant " I don't think 'natural order' (as in DMBS) of an EHR can be of 
POMR type"



Cheers,



-koray



From: Koray Atalag
Sent: Wednesday, 26 November 2014 9:52 p.m.
To: 'For openEHR technical discussions'
Subject: RE: Problem-oriented records and querying by problem



Hi All,



The single care plan giving way to multiple views makes sense to me as well. I 
don't think with so many degrees of freedom in modelling with openEHR we cannot 
possibly reconcile the many different care plans post-hoc to create the really 
valuable master view for purposes Heather nicely put. Having spend entire last 
week in a major HIS procurement evaluation I must say this looks like the way 
things are already been implemented in many places around the world! I also 
have noted the current immaturity of using links effectively to do things just 
like this - maybe we need some 'design patterns' which Tom had indicated some 
time ago.



Another point is, although I haven't been practicing Medicine for too long now, 
I know the links between problems vs goals vs actions do not play nicely at all 
times - indeed for most of the time. They can be subjective and quite error 
prone. Therefore I don't think 'natural order' (as in DMBS) of an EHR cannot be 
of POMR type - it has to follow real life: randomness and episodicity. Maybe we 
should look at putting a quantifier for the "likelihood" of the links - any 
thoughts?



Cheers,



-koray



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bj?rn N?ss
Sent: Tuesday, 25 November 2014 8:02 p.m.
To: For openEHR technical discussions
Subject: Re: Problem-oriented records and querying by problem



I like this approach.  The master care plan is what we call Patient plan.  
There should be only one of this in a given EHR. This plan evolves over time as 
more items are addes or removed.



To administer this plan you need a dashboard with functionality to filter on 
overdue,  finished,  etc. And of course you need commands like add, update,  
finish, etc.



The plan is a master view on plan items from different systems and with 
contributions from all health care specialities.



Depending on the users point of view it should be possible to dig into details 
about specific parts of the plan.



I am not sure if it is possible to archetype this dashboard.  I guess this is 
up to the application to implement this.  The clinical modeller should 
archetype the content of different plan items.  To make this work we need a 
basic set of INSTRUCTON/ACTIVITY/ACTION archetypes that make the outer 
boundaries of a care plan and care plan elements.





Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

 Original message 

From: Thomas Beale

Date:20/11/2014 19:07 (GMT+01:00)

To: openehr-technical at lists.openehr.org<mailto:openehr-technical at 
lists.openehr.org>

Subject: Re: Problem-oriented records and querying by problem




I wonder if the GP 'master care plan' is more like a 'care plan
dashboard' rather than an actual care plan? With functions like 'show
all overdue / suspended / etc etc'...

- thomas

On 20/11/2014 17:25, Heather Leslie wrote:
> Hi Karsten,
>
> I think in practice you will see a variety of care plans depending on the 
> context.
>
> The endocrinologist will be using a diabetes care plan for their care of the 
> patient, and likely not having access to, nor particularly interested in, 
> what other specialists might be scheduling.
>
> The cardiologist will be using a cardiology-protocol-based care plan, 
> probably developed in splendid isolation from the endocrinologist activities.
>
> The rehab specialist will be using a purpose-built care plan for the 
> patient's recovery from a knee replacement.
>
> However it will be critical that the GP or coordinating primary care provider 
> develop/need a single global care plan, (which can be separated out for the 
> different purposes, if needed) that provides an overview of all activities 
> that the patient requires - what is due, overdue, planned etc. This will 
> ensure that the blood glucose and renal function tests required by both the 
> endocrinologist and cardiologist iare coordinated, if clinically appropriate 
> and tests/appts not repeated unnecessarily. They will have access to a 
> 'master' plan that will detail all reviews/goals/test/appointments for each 
> 'specialty' plan and have the ability to coordinate the components to suit 
> the best interests of the patient as a whole - a care plan for the patient, 
> not just one per problem.
>
> The patient or the parent/caregiver will also benefit with being able to 
> schedule appointments/t

Problem-oriented records and querying by problem

[Koray Atalag]

Hi All,



The single care plan giving way to multiple views makes sense to me as well. I 
don't think with so many degrees of freedom in modelling with openEHR we cannot 
possibly reconcile the many different care plans post-hoc to create the really 
valuable master view for purposes Heather nicely put. Having spend entire last 
week in a major HIS procurement evaluation I must say this looks like the way 
things are already been implemented in many places around the world! I also 
have noted the current immaturity of using links effectively to do things just 
like this - maybe we need some 'design patterns' which Tom had indicated some 
time ago.



Another point is, although I haven't been practicing Medicine for too long now, 
I know the links between problems vs goals vs actions do not play nicely at all 
times - indeed for most of the time. They can be subjective and quite error 
prone. Therefore I don't think 'natural order' (as in DMBS) of an EHR cannot be 
of POMR type - it has to follow real life: randomness and episodicity. Maybe we 
should look at putting a quantifier for the "likelihood" of the links - any 
thoughts?



Cheers,



-koray



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bj?rn N?ss
Sent: Tuesday, 25 November 2014 8:02 p.m.
To: For openEHR technical discussions
Subject: Re: Problem-oriented records and querying by problem



I like this approach.  The master care plan is what we call Patient plan.  
There should be only one of this in a given EHR. This plan evolves over time as 
more items are addes or removed.



To administer this plan you need a dashboard with functionality to filter on 
overdue,  finished,  etc. And of course you need commands like add, update,  
finish, etc.



The plan is a master view on plan items from different systems and with 
contributions from all health care specialities.



Depending on the users point of view it should be possible to dig into details 
about specific parts of the plan.



I am not sure if it is possible to archetype this dashboard.  I guess this is 
up to the application to implement this.  The clinical modeller should 
archetype the content of different plan items.  To make this work we need a 
basic set of INSTRUCTON/ACTIVITY/ACTION archetypes that make the outer 
boundaries of a care plan and care plan elements.





Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

 Original message 

From: Thomas Beale

Date:20/11/2014 19:07 (GMT+01:00)

To: openehr-technical at lists.openehr.org

Subject: Re: Problem-oriented records and querying by problem




I wonder if the GP 'master care plan' is more like a 'care plan
dashboard' rather than an actual care plan? With functions like 'show
all overdue / suspended / etc etc'...

- thomas

On 20/11/2014 17:25, Heather Leslie wrote:
> Hi Karsten,
>
> I think in practice you will see a variety of care plans depending on the 
> context.
>
> The endocrinologist will be using a diabetes care plan for their care of the 
> patient, and likely not having access to, nor particularly interested in, 
> what other specialists might be scheduling.
>
> The cardiologist will be using a cardiology-protocol-based care plan, 
> probably developed in splendid isolation from the endocrinologist activities.
>
> The rehab specialist will be using a purpose-built care plan for the 
> patient's recovery from a knee replacement.
>
> However it will be critical that the GP or coordinating primary care provider 
> develop/need a single global care plan, (which can be separated out for the 
> different purposes, if needed) that provides an overview of all activities 
> that the patient requires - what is due, overdue, planned etc. This will 
> ensure that the blood glucose and renal function tests required by both the 
> endocrinologist and cardiologist iare coordinated, if clinically appropriate 
> and tests/appts not repeated unnecessarily. They will have access to a 
> 'master' plan that will detail all reviews/goals/test/appointments for each 
> 'specialty' plan and have the ability to coordinate the components to suit 
> the best interests of the patient as a whole - a care plan for the patient, 
> not just one per problem.
>
> The patient or the parent/caregiver will also benefit with being able to 
> schedule appointments/tests etc.
>
> And we will need to be able to break down that master care plan to see which 
> components belong with each problem, or are shared between problems, and for 
> context-based sharing with other health care providers.
>


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



__ Information from ESET NOD32 Antivirus, version of virus signature 
database

My first steps in setting the OpenEHR Server

[Koray Atalag]

Hi Osama,



I'm very interested in your project - we have developed and deployed a 
gestational diabetes registry in New 
Zealand
 using the Ocean platform. Would be keen to hear about your progress. If you 
can give a little more details about your clinical modelling needs I'm sure 
people on the list will help you find right archetypes if they exist. For us 
the Nehta and openEHR CKM were main sources. All the best.



Cheers,



-koray



-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Osama Elhassan SeedAhmed Elhassan
Sent: Sunday, 9 November 2014 8:39 a.m.
To: pablo pazos; openeh technical
Subject: RE: My first steps in setting the OpenEHR Server



Dear Pablo,



Thanks for your valuable support. .

Both the ehr and emr servers could be able to connect to each other 1. Create 
the record in ehr from emr 2. Read the record 3. I saw the result also stored 
in the ehr



I am planning to develop a case study to model a tuberculoses registry in which 
suspected cases will be reported The final diagnosis worksflow might include 
several types of tests and treatements. I intend to follow an well-known WHO 
protocol.

I have few questions:



Are there any ready-made archtypes that I can reuse for this purpose? Is GDL 
ready to be used to map the workflow rules to the archetype varaibales? I would 
be very grateful if you have an explanatory GDL exmaple.



best regards,



Osama





From: pablo pazos [pazospa...@hotmail.com]

Sent: Saturday, November 08, 2014 9:40 PM

To: Osama Elhassan SeedAhmed Elhassan; openeh technical

Subject: RE: My first steps in setting the OpenEHR Server



Hi Osama,



EHRServer uses Grails 2.1.0



https://github.com/ppazos/cabolabs-ehrserver/blob/master/application.properties





app.grails.version=2.1.0

app.name=ehr

app.version=0.1

plugins.quartz=1.0-RC2





Please use that version of Grails, do a "grails clean" then "grails run-app". 
If you run the app using a different version, Grails will ask to upgrade, that 
might change some code and break things, please use a clean version downloaded 
from github with Grails 2.1.0.



To have something in the EHR you need to commit documentos to the EHR. Please 
check this app that does just that: https://github.com/ppazos/cabolabs-emrapp







--

Kind regards,

Eng. Pablo Pazos Guti?rrez

http://cabolabs.com>



> From: OEElhassan at dha.gov.ae

> To: pazospablo at hotmail.com; 
> openehr-technical at lists.openehr.org lists.openehr.org>

> Subject: RE: My first steps in setting the OpenEHR Server

> Date: Sat, 8 Nov 2014 17:26:07 +

>

> Hi Pablo and thanks for your timely response. Below is my answer to your 
> questions:

>

> First I downloaded the following ehr server version. quartz library version 
> was different in staring up and lot of compilation errors.

> ===

> app.grails.version=1.3.7

> app.name=ehr

> app.servlet.version=2.4

> app.version=0.6

> plugins.hibernate=1.3.7

> #plugins.quartz=0.4.1

> #plugins.quartz=1.0-RC2

> plugins.tomcat=1.3.7

> 

>

>

> I ignored the above version.

> -

>

>

>

>

> After that I downloaded the following version

>

> grails.servlet.version = "2.5"

> app.grails.version=2.1.1

> app.name=ehr

> app.version=0.1

> plugins.quartz=1.0-RC2

> ==

>

> This server is running fine but it is not showing showEHR report.

>

>

>

> In the controller code it is referring import

> org.codehaus.groovy.grails.commons.ApplicationHolder

>

> I have to replace the ApplicationHolder which is already obsolete.

> with the appropriate class,

>

>

> best regrads,

>

> Osama

> 

> From: pazospablo at hotmail.com [pazospablo 
> at hotmail.com]

> Sent: Saturday, November 08, 2014 6:17 PM

> To: Osama Elhassan SeedAhmed Elhassan;

> openehr-technical at lists.openehr.org lists.openehr.org>

> Subject: Re: My first steps in setting the OpenEHR Server

>

>

> Ho Osama,

>

>

> Can you provide a full stack trace?

>

>

> Which version of grails do you have? And JDK version?

>

>

> Cheers,

>

> Pablo Pazos

>

> www.CaboLabs.com>

>

> -- Original message--

>

> From: Osama Elhassan SeedAhmed Elhassan

>

> Date: Sat, Nov 8, 2014 11:16 AM

>

> To: openehr-technical at lists.openehr.org lists.openehr.org>;

>

> Su

Any prep for MIE 2015 in Madrid?

[Koray Atalag]

Hi, I was just wondering if there's any activity planned for MIE 
2015 in next May - the deadline for submissions has 
just been extended:

Deadline for Papers and Posters (indexed)  is extended to November 17th, 2014
Deadline for Workshops, Panels, Special events (nonindexed) proposals is 
December 1st.

If nothing I guess there will be some individual participations - I'm keen to 
attend and coordinate things.

Cheers,

-koray

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

Texts about transforming between openEHR and other formalisms

[Koray Atalag]

Hi All, reposting this as I just noticed it didn?t get thru list server.

Basically I?ve recently updated an openEHR bibliography list on 
Zotero<https://www.zotero.org/groups/openehr> which I?ve been curating for a 
while. For those of you who use it Zotero (open source and plug-in to Firefox) 
is clearly the best! My PhD student and I can manage entries ? if you are an 
expert Zotero user and an academician and interested in supporting its curation 
please contact me and I?ll add you to the group who can add/edit citations 
(with full text access). Unfortunately we cannot share full text publicly.


Cheers,

-koray

From: Koray Atalag
Sent: Friday, 26 September 2014 9:58 a.m.
To: For openEHR technical discussions
Cc: For openEHR clinical discussions
Subject: RE: Texts about transforming between openEHR and other formalisms


Thanks Diego - that's an impressive list.



This reminded me something I started quite a few years ago - an online up to 
date bibliography of openEHR (https://www.zotero.org/groups/openehr) and 
closely related papers. I used the open source Zotero (http://zotero.org) which 
links to my browser plug-in (you can add while you browse, fantastic sensing 
and resolving of metadata and has word plug-in to cite and create reference 
list as well) so I could keep on adding new stuff as I find but also let the 
community grow the list as well. Much better than personal effort to keep up to 
date! As I remember there were a few constraints and inconveniences at that 
time and I'll see if it is any better now - but ultimately I think we should 
look at maintaining such a list and make available from openEHR website too.



Any appetite / volunteers? Obviously we can't let everyone write access - it'll 
have to be a few of us academics to do the QA too.



Cheers,



-koray





-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Diego Bosc?
Sent: Thursday, 25 September 2014 8:51 p.m.
To: For openEHR technical discussions
Subject: Re: Texts about transforming between openEHR and other formalisms



I have the same doubts as Ian about which kinds of transformations you are 
looking for, so I'll give you a summary :)





Here we have done several works regarding data instance transformation based on 
archetypes:



- Maldonado, J. A., Moner, D., Tom?s, D., ?ngulo, C., Robles, M., & Fern?ndez, 
J. T. (2007). Framework for clinical data standardization based on archetypes. 
Studies in health technology and informatics, 129(1), 454.



- Moner, D., Maldonado, J. A., Bosca, D., Fern?ndez, J. T., Angulo, C., Crespo, 
P., ... & Robles, M. (2006, August). Archetype-based semantic integration and 
standardization of clinical data. In Engineering in Medicine and Biology 
Society, 2006. EMBS'06. 28th Annual International Conference of the IEEE (pp. 
5141-5144). IEEE.



- Moner, D., Maldonado, J. A., Bosc?, D., Angulo, C., Robles, M., P?rez, D., & 
Serrano, P. (2010, May). CEN EN13606 normalisation framework implementation 
experiences. In Seamless Care, Safe Care: The Challenges of Interoperability 
and Patient Safety in Health Care:

Proceedings of the EFMI Special Topic Conference, June 2-4, 2010, Reykjavik, 
Iceland (Vol. 155, p. 136). IOS Press.



- Maldonado, J. A., Moner, D., Bosca, D., Angulo, C., Marco, L., Reig, E., & 
Robles, M. (2011, July). Concept-based exchange of healthcare

information: The LinkEHR approach. In Healthcare Informatics, Imaging and 
Systems Biology (HISB), 2011 First IEEE International Conference on (pp. 
150-157). IEEE.



- Mart?nez Costa, C., Men?rguez-Tortosa, M., & Fern?ndez-Breis, J. T.

(2011). Clinical data interoperability based on archetype transformation. 
Journal of biomedical informatics, 44(5), 869-880.



- Moner, D., Moreno, A., Maldonado, J. A., Robles, M., & Parra, C.

(2012, August). Using archetypes for defining CDA templates. In MIE (pp. 53-57).



- Moner D. LinkEHR Studio: a tool for archetype-based data transformations. 
Arctic Conference 2014

(http://vimeo.com/channels/764149)





Model transformations:



- Mart?nez-Costa, C., Men?rguez-Tortosa, M., & Fern?ndez-Breis, J. T.

(2010). An approach for the semantic interoperability of ISO EN 13606 and 
OpenEHR archetypes. Journal of biomedical informatics, 43(5), 736-746.



- Mart?nez-Costa, C., Bosca, D., Legaz-Garc?a, M. C., Tao, C., Fern?ndez, B. 
J., Schulz, S., & Chute, C. G. (2012). Isosemantic Rendering of Clinical 
Information Using Formal Ontologies and RDF.

Studies in health technology and informatics, 192, 1085-1085.



- Lezcano, L., Sicilia, M. A., & Rodr?guez-Solano, C. (2011).

Integrating reasoning and clinical archetypes using OWL ontologies and SWRL 
rules. Journal of biomedical informatics, 44(2), 343-353.



- Detailed Clinical Models to facilitate inter-standard interoperability of 
data types. Diego Bosc?, Jos? Alberto Maldonado, David M

How to model relationship between archetypes?

[Koray Atalag]

Interesting - reposting this as my University has changed reply-to address so 
lists haven't been accepting my posts. Funny that I am only aware of this as 
Outlook places sent mail under that thread nicely - makes you think it's 
actually posted by the list manager!


Cheers,

-koray

From: Koray Atalag
Sent: Tuesday, 16 September 2014 10:32 p.m.
To: For openEHR technical discussions
Subject: RE: How to model relationship between archetypes?

Hi Li Wang,

In my opinion what you want is an ability to relate instances of data not 
individual archetypes themselves. I can see a couple things going here; for 
example the implicit INSTRUCTION - ACTION relationships (BTW you should be 
using these archetype classes and not OBSERVATION).

I reckon you are happy to use LINK but make sure it fulfils your needs as the 
relationship can only be made between EHRs or COMPOSITIONS. There's some 
ambiguous description about internal usage - perhaps it'd be good to have 
feedback from someone else who have used this?? Otherwise I'd advise you to 
find another means to store any special relationship for your needs.

The LINK type defines a logical relationship between two items, such as two
ENTRYs or an ENTRY and a COMPOSITION. Links can be used across compositions,
and across EHRs. Links can potentially be used between interior (i.e. non
archetype root) nodes, although this probably should be prevented in archetypes.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of li wang
Sent: Friday, 12 September 2014 4:17 a.m.
To: For openEHR technical discussions
Cc: For openEHR technical discussions
Subject: Re: How to model relationship between archetypes?

Thanks for your reply!

I think link is a good fit in my model.
And I will go through the specification in more detail.
Still I'm glad to hear any suggestion on this questions.

Thanks!

Kind regards,
Li Wang

On Sep 11, 2014, at 11:37 PM, Athanasios Anastasiou mailto:a.anastasiou at swansea.ac.uk>> wrote:
Hello Wang

Please see below:

   > My model is simple, an doctor requests a lab test and gets 
corresponding
   > result, and the result are related to the request.
Great, what is the real world need that triggers the design of this
template? What is the purpose for this doctor's request? Is this to
cover a standard procedure that is going on in the Health System or to
serve the purposes of a specific research project?

   > For example, if the
   > doctor orders two lab test requests, full-blood-count-request and
   > liver-function-request, then there are two lab test results,
   > full-blood-count-result and liver-function-result, and the
   > full-blood-count-result is related to the full-blood-count-request, the
   > liver-function-result is related to the liver-function-request. So that
   > the corresponding result can be found from the request and vice versa.
My perception from the way you describe this use case is that you don't
need a template that brings the archetypes together. What you can do is
create (or re-use) an archetype for your INSTRUCTION. This will have its
own lifetime within the EHR. Furthermore, you can create (or re-use)
another archetype for your OBSERVATION that will contain a link (perhaps
of type "related_to") to the INSTRUCTION that generated it.

There is a detail here that I am not sure about and this is that an
INSTRUCTION will trigger a set of ACTIONs and ACTIVITYs of which one
could be leading to the generation of the actual OBSERVATION. In this
case, there will effectively be a trace between the OBSERVATION and the
INSTRUCTION but I am not sure if that would be as easily query able.

   > In programming language, a possible implementation I think may be that
   > there are two classes, lab-test-request and lab-test-result,
   > lab-test-result has an attribute stores id of lab-test-request 
instances
   > to hold the relationship between these two classes.
   > Does use LINK in archetypes go the same way? The LINK attribute
   > in archetype lab test result points to archetype lab test request, and
   > in lab test result archetype instance the LINK attribute stores id of
   > lab test request archetype instance? Is that right?
I would advise against thinking in programming terms when you are at the
level of archetype/templates. When you are "up there" it is better to
think in terms of the real-world, the real need, the facts and processes
of reality. Data and information will be captured within the EHR no
matter what the back-end gets to be (relational, graph, other).


   > And how to use template to model the relationship between lab test
   > request and lab test result?
I get the sense that you need to do a bit of background reading about
how the whole thing works and f

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

[Koray Atalag]

Hi Pablo,

This makes a lot of sense to me as well.
Re ontology section there may be terminology service queries to things like 
snomed or formal ontologies. So I'd assume what comes back could potentially be 
considered as an ontology. Also bear in mind there is no agreed separation of 
what is terminology vs ontology as far as it goes so sticking to ontology is 
probably more inclusive for now. I think one needs to consider usage rather 
than composition for correct labelling - so for example a group of snomed terms 
that form a value set can be considered as terminology on the basis of usage 
but results of a terminology service returning a hierarchy of terms will look 
more like an ontology. Anyway I'm sure this is more an academic concern than 
real ;)

Cheers,

-koray

From: openEHR-technical [openehr-technical-bounces at lists.openehr.org] on 
behalf of pablo pazos [pazospa...@hotmail.com]
Sent: Friday, 24 January 2014 4:47 a.m.
To: openeh technical
Subject: RE: radical idea - where term value sets should be defined in  
archetypes.

HI all,

I agree with Daniel's idea: having the terminology items physically inside the 
value set, so the value set itself will be a new terminological construct and 
we'll have both: terms and sets. This is clearer and simpler than havnig 
external relationships (is simpler to parse, implement in code and traverse the 
structure by a program).

BTW, I would prefer that "ontology" section would be called "terminology" in 
future versions of ADL/AOM. IMO this is more correct naming.

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

> Date: Tue, 14 Jan 2014 17:45:21 +
> From: thomas.beale at oceaninformatics.com
> To: openehr-technical at lists.openehr.org
> Subject: Re: radical idea - where term value sets should be defined in 
> archetypes.
>
> On 14/01/2014 10:52, Daniel Karlsson wrote:
> > 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.
> >
>
> Yep, I'm ok with any of those. One version I originally thought of -
> Daniel's first alternative above:
>
> ["vs1001"] = <
> text = <"Blood pressure measuring position">
> description = <"Position of patient at time of measuring blood pressure.">
> content = <"at1001", "at1002", "at1003", ...>
> >
>
>
> We can put more or less any alternative that works - happy to see what
> the discussion here might generate.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Ocean's Template Designer and allowedType rules

[Koray Atalag]

Hi folks,

We used opt to feed in the model to software, especially the GUI generator in 
GastrOS.
We added a few GUI Directives to get the desired looks...
I reckon the new version of TD now supports those directives :)
For those interested it is open source at: http://gastros.codeplex.com

Cheers,

-koray


-Original Message-
From: openEHR-implementers 
[mailto:openehr-implementers-boun...@lists.openehr.org] On Behalf Of Ian 
McNicoll
Sent: Friday, 15 November 2013 8:31 p.m.
To: For openEHR technical discussions
Cc: openehr implementers
Subject: Re: Ocean's Template Designer and allowedType rules

Hi Pablo,

I just want to re-emphasise Heath's point for anyone looking to implement 
openEHR template support. Your start point should be the .opt 'Operational 
template' format. This is what is used by a number of developers to generate 
downstream artefacts such asd code fragments, xsd schema and GUI generation.

The official openEHR templates will be fully based on ADL1.5, rather than the 
current mix of ADL1.4 and Ocean .oet, but the eventual ADL
1.5 .opt output will be very similar to the current .opt, so this is a good 
'junction point' for transition from ADL1.4 -> ADL 1.5

Ian

On 14 November 2013 21:27, Heath Frankel  wrote:
> Hi Pablo,
>
> The OET format is an internal format. You should export the template 
> as an OPT and you will get a AOM and RM based output.
>
>
>
> Heath
>
>
>
> From: openEHR-technical 
> [mailto:openehr-technical-bounces at lists.openehr.org]
> On Behalf Of pablo pazos
> Sent: Friday, 15 November 2013 1:06 AM
> To: openeh technical; openehr implementers
> Subject: Ocean's Template Designer and allowedType rules
>
>
>
> Hi all,
>
>
>
> I'm playing with the TD v2.7.60Beta to include openEHR template 
> support to CaboLabs EHRServer 
> (http://www.youtube.com/watch?v=D-hs-Ofb8SY)
>
>
>
> I opened the Blood Pressure archetype and tryied to constraint the Any 
> Event node of type EVENT to allow only POINT_EVENT, and I get this rule:
>
>
>
>
>
>   
>
> PointInTime
>
>   
>
> 
>
>
>
> Shouldn't "PointInTime" be "POINT_EVENT"?
>
>
>
> Is there any reason for the TD to not use openEHR datatype names?
>
>
>
> Where can I find all the names used to constraint allowedTypes in TD?
>
>
>
> Thanks!
>
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.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-implementers mailing list
openEHR-implementers at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Exchanging data

[Koray Atalag]

Hi Mate ? and also mate as people often greet each other in New Zealand J



Well done with all the great work ? which sounds very impressive.

I?m particularly interested in the ?Register of registers? concept ? can you 
please elaborate on this?

A PhD candidate of mine is planning to establish some ?decision support? tool 
for modellers by looking at a number of model sources, including other CKMs and 
some relevant ontologies, DCMs, CDA etc. Do you see a match?



Cheers,



-koray



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Mate Be?tek
Sent: Wednesday, 16 October 2013 12:13 a.m.
To: For openEHR technical discussions
Subject: Re: Exchanging data



Hi from Slovenia!



We've been able to use OpenEHR on many levels. This includes the national 
eHealth project, a research project (eCare) where an OpenEHR based platform for 
development of new behavior change interventions was developed and used for a 
year in controlled clinical trials (the interventions were tested), also while 
working for the epSOS project and for defining our national EHR "content 
modules", we used OpenEHR archetypes and templates.

To use OpenEHR you need an OpenEHR repository where both the archetypes and 
data are stored (e.g. in a form of xml documents that are controlled by the 
OpenEHR xml schema). To use the data one can use a query languege (AQL or 
XPATH/XQUERY) to get the data which can then be used for different purposes 
(like creating CDA document ). If working directly with xml documents, you can 
use XSLT for performing transformations between OpenEHR xml schema and CDA 
schema. In the other direction, you can also use XSLT, obviously. Anyhow, there 
are a few open source OpenEHR repositories which come with frameworks for 
developing new OpenEHR based applications that run on top of OpenEHR 
repositories.



In Slovenia, we have a national EHR (IHE based) where CDA is used for the 
documents. While I worked on the national eHealth project we defined OpenERH as 
the way to model clinical content and we are currently (the Slovenian MoH is) 
in the process of establishing the national process of OpenEHR governance. And 
plenty more on this topic is happening in Slovenia. The latest PARENT project 
is also something to note - the register of registers is probably going to use 
OpenEHR as the basis.



Kind regards

Mate



2013/10/15 Mate Be?tek mailto:mate.bestek at 
gmail.com>>

Pozdrav i iz Slovenije!



Kod nas je OpenEHR prili?no daleko dogurao. Osobno sam ga upotrijebljivao na 
nacionalnom eZdravje projektu te nekoliko ostalih projekata (znam da se PARENT 
isto tako poku?ava osloniti na OpenEHR). Kako je ve? bilo re?eno, potreban je 
OpenEHR server u koji se pohranivaju podatci zajedno za arhetipima. Sa 
upotrebom nekog query jezika (npr. AQL ili XPATH/XQUERY) dobiva se podatke, 
koje se mo?e onda upotrijebiti npr. za CDA dokumente. Isto tako u kontra 
smijeru, radi se transformacija iz npr. CDA u OpenEHR pomo?u XSLT. Postoje ve? 
nekoliko open source projekata, koji slu?e kao OpenEHR repozitorij i kao 
framework za izgradnju aplikacija iznad tog repozitorija.



LP,Mate









2013/10/15 Miroslav Koncar mailto:miroslav_koncar 
at yahoo.com>>

sebe transformaciju podataka iz cega god radi u openEHR, ADL. Ako pak imate dva 
sustava koji su openEHR kompatibilni, onda je stvar puno laksa, jer formalizam 
osigurava verzioniranje archetypes, odnosno oba kroz templates meto







__ Information from ESET NOD32 Antivirus, version of virus signature 
database 8927 (20131016) __



The message was checked by ESET NOD32 Antivirus.



http://www.eset.com

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

SV: ACTIVITY and timing

[Koray Atalag]

Hi Pablo & all,

I'm working on the medication list at the moment and have had discussion with 
others.
I think the RM timing attribute really refers to the date/time when the 
information about that Activity was committed - not necessarily the actual time 
the event modelled in an Action type of entry. So it can be an arbitrary 
date/time, e.g. within the next 2 weeks etc. It may not happen in real life 
(e.g. waiting lists or patient no show etc.) but if/when happens the ACTION 
will capture that.

A related issue, I think it'd be a good idea to include within the archetype 
very clear description of timing (as opposed to capturing using RM date/time 
from a series of related archetypes) for summary type records (e.g. medicines 
list, care summaries, reconciliation report etc.) I think it is a bit too much 
to expect EHR systems to look at each and every relevant archetype (in this 
case Instruction and Action types) and create a summary view by finding which 
one is the beginning, most recent etc. While individual events' timing can be 
dealt with RM timing attribute I think summary type instances should capture 
this information. Anyway I may be wrong or even not directly an answer to 
current topic but relevant.

Cheers,

-koray

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Wednesday, 14 August 2013 3:24 a.m.
To: openEHR Clinical; openeh technical
Subject: RE: SV: ACTIVITY and timing

Hi Thomas, thanks for the input, is great to understand the rationale behind 
ACTIVITY.timing.

Right now I've more questions than proposals :)

"...The RM says that ACTIVITY.timing should always be present, and i believe it 
should be, otherwise processing software doesn't know what to do..."

Should all INSTRUCTION/ACTIVITIES be processed by a processing software?

My guess is no, but maybe I'm wrong. It would be great to hear arguments on 
that.


The need for timing seems to be required for medication INSTRUCTIONs, or 
generalizing that: all INSTRUCTIONS that involve some kind of event 
repetition/frequency.

But what about LAB/RAD requests? Those are one time events, and their execution 
depends on scheduling, i.e. timing on request could not be something formal and 
specific. In practice, the only time specification I know for LAB/RAD requests 
is the urgent flag, and the real time of execution depends on the resource 
availability on each health center.

What do you think about timing specification of ACTIVITIES that have no 
repetitions?
What values should we use for ACTIVITY.timing when recording a RAD request?


BTW, for all in this discussion, there are some awesome slides from Sam that 
shows different timing options for medication: 
http://www.slideshare.net/atalagk/what-if-we-never-agree-on-a-common-health-information-model
 (form slide 6)

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

Date: Tue, 13 Aug 2013 12:04:12 +0100
From: thomas.beale at 
oceaninformatics.com
To: openehr-technical at lists.openehr.org; openehr-clinical at 
lists.openehr.org
Subject: Re: SV: ACTIVITY and timing

Hi Bjorn, Pablo,
we originally put in the timing field in ACTIVITY as a DV_PARSEABLE precisely 
because there seemed to be no accepted standard for representing this 
information. I think there is still no single accepted standard, but I think 
that possible standards are better understood.

One of the complicating factors is that timing that is linked to real world 
events (e.g. 'take one after evening meal') doesn't have a widely accepted 
representation. The HL7 GTS format is not widely liked, and probably doesn't 
deal with enough situations anyway. But it was a decent attempt, and i for one 
don't know of any standard that cleanly mixes purely clock timing concepts with 
real world events.

The RM says that ACTIVITY.timing should always be present, and i believe it 
should be, otherwise processing software doesn't know what to do , if it is 
optional. It should always be meaningful as well, even if it's not guaranteed 
to be 100% correct. By that I mean that this field can only contain parseable 
(and therefore formal) timing expressions that might provide the overall 
correct dosage picture, e.g. 'every 8 hours', but extra information might be 
provided somewhere else to refine that, e.g. to say 'after meals'.

However, the danger is that timing information provided elsewhere is not 
standardised. The timing archetype in CKM is as follows:
[cid:image001.png at 01CE98D1.956B3120]
There is a parseable expression as the last item.

I think to solve this properly, we would need to understand:

  *   the range of requirements of clinical modellers (we know many basic 
needs, but I am sure in recent years, more exotic timing requirements have been 
disco

Recording absence of (clinical) information

[Koray Atalag]

Hi everyone,



This is to do with my long standing issue about recording absence of info. In 
endoscopy models the "Presence" of endoscopic findings was represented as a 
CLUSTER where a special ELEMENT (that is internally referenced many times for 
each finding thereafter) captured "Presence" of a finding and also  if/why 
information about a particular finding was not available. This I thought was a 
quick and dirty fix to a larger problem which I reckon applies to all data 
structures and types including ENTRY Class itself.



I came across this in NEHTA medication archetypes:

COMPOSITION.Medication_List has "Absent Info slot filled by 
openEHR-EHR-EVALUATION.absence.v1 (and specialisations) that has only one 
ELEMENT which captures absence (free or coded text)

Description says: Positive statement that no information is available about 
medication use.



While this approach solves the current problem in the long term and in order to 
enable a global scale interoperability it seems to be another quick & dirty 
fix. To me this is a crystal clear pattern for clinical information (and 
potentially administrative too) - shouldn't this be handled in RM?



Sorry if this has already been dealt with - I haven't been able to read all 
discussions for a while.



Cheers,



-koray



Koray Atalag, MD, PhD, FACHI

Senior Research Fellow

Description: Description: Description: cid:image001.png at 01CD2460.A69C1680

School of Population Health, The University of Auckland

Private Bag 92019 Auckland 1142, New Zealand

Email: k.atalag at nihi.auckland.ac.nz<mailto:k.atalag at nihi.auckland.ac.nz> 
| Web: www.nihi.auckland.ac.nz<http://www.nihi.auckland.ac.nz/>

Skype: atalagk  Mob: 021 02412096  DDI: +64 9 923 7199



-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130715/91596c41/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4493 bytes
Desc: image001.jpg
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130715/91596c41/attachment.jpg>

Help needed: what's out there? medication list, allergies and adverse reactions

[Koray Atalag]

g to our national terms, but I prefer to use Australian Medicine 
Terminology instead.  I'd like to know of all of you, which is the better 
choice. I read one NZ paper dedicated to that issue, but it dates back a couple 
of years already, so I'd really appreciate to learn from your experience.

We're definitely going mainstream, I'm very proud to be part of  this community.

Cheers,

Jussara R?tzsch
openEHR Foundation

Enviado via iPad

Em May 30, 2013, ?s 8:16 PM, Koray Atalag mailto:k.atalag at nihi.auckland.ac.nz>> escreveu:
Hi All,

As you may already know New Zealand have decided to used openEHR Archetypes for 
modelling an Exchange Content 
Model<http://www.ithealthboard.health.nz/content/health-information-exchange-architecture-building-blocks>
 for the purpose of standardising payload content during health information 
exchange (HIE). Of course there?s heaps of prior work done, mostly propriety 
dataset specifications we well as some v2 based constructs and now CDA 
templates. We also decided to go with CDA as the common payload between 
systems, preferably with a web-services based connectivity. So ideally the 
content model will be defined using Archetypes that will then be templated for 
specific use-cases (e.g. eReferrals) and finally create final CDA payload (as 
much automatically as we can). And then the propagation of any changes needed 
in that exchange will be from the Content Model to CDA ? so these will remain 
linked. However initially we need to run the cycle backwards: I?ve been tasked 
by the government to review existing CDA templates and former standards and 
build part of the content model for medication list, allergies and adverse 
reactions by harmonising with what?s standing out there as good/reusable 
examples. Of course first place to look at is openEHR and NEHTA CKM but I know 
a great deal of stuff is also out there. I?m hoping that once we get the 
essentials done we can resume the normal lifecycle.

I?d really appreciate if you could share if there?s any relevant work that you 
think might worth looking at. I?m particularly interested in other national 
CKM?s. Many thanks in advance.

Cheers,

-koray
www.openehr.org.nz<http://www.openehr.org.nz>

Koray Atalag, MD, PhD, FACHI
Senior Research Fellow

School of Population Health, The University of Auckland
Private Bag 92019 Auckland 1142, New Zealand
Email: k.atalag at nihi.auckland.ac.nz<mailto:k.atalag at nihi.auckland.ac.nz> 
| Web: www.nihi.auckland.ac.nz<http://www.nihi.auckland.ac.nz/>
Skype: atalagk  Mob: 021 02412096  DDI: +64 9 923 7199


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 8394 (20130530) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
___
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at 
lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130604/ebb15adf/attachment-0001.html>

Help needed: what's out there? medication list, allergies and adverse reactions

[Koray Atalag]

Hi All,



As you may already know New Zealand have decided to used openEHR Archetypes for 
modelling an Exchange Content 
Model<http://www.ithealthboard.health.nz/content/health-information-exchange-architecture-building-blocks>
 for the purpose of standardising payload content during health information 
exchange (HIE). Of course there's heaps of prior work done, mostly propriety 
dataset specifications we well as some v2 based constructs and now CDA 
templates. We also decided to go with CDA as the common payload between 
systems, preferably with a web-services based connectivity. So ideally the 
content model will be defined using Archetypes that will then be templated for 
specific use-cases (e.g. eReferrals) and finally create final CDA payload (as 
much automatically as we can). And then the propagation of any changes needed 
in that exchange will be from the Content Model to CDA - so these will remain 
linked. However initially we need to run the cycle backwards: I've been tasked 
by the government to review existing CDA templates and former standards and 
build part of the content model for medication list, allergies and adverse 
reactions by harmonising with what's standing out there as good/reusable 
examples. Of course first place to look at is openEHR and NEHTA CKM but I know 
a great deal of stuff is also out there. I'm hoping that once we get the 
essentials done we can resume the normal lifecycle.



I'd really appreciate if you could share if there's any relevant work that you 
think might worth looking at. I'm particularly interested in other national 
CKM's. Many thanks in advance.



Cheers,



-koray

www.openehr.org.nz<http://www.openehr.org.nz>



Koray Atalag, MD, PhD, FACHI

Senior Research Fellow

Description: Description: Description: cid:image001.png at 01CD2460.A69C1680

School of Population Health, The University of Auckland

Private Bag 92019 Auckland 1142, New Zealand

Email: k.atalag at nihi.auckland.ac.nz<mailto:k.atalag at nihi.auckland.ac.nz> 
| Web: www.nihi.auckland.ac.nz<http://www.nihi.auckland.ac.nz/>

Skype: atalagk  Mob: 021 02412096  DDI: +64 9 923 7199

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130530/9e1b0fe2/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4493 bytes
Desc: image001.jpg
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130530/9e1b0fe2/attachment.jpg>

Archetypes at OMG

[Koray Atalag]

Hi Tom, this is an exciting thing. OMG sets the standards for sure...



Cheers,



-koray



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Wednesday, 22 May 2013 10:07 a.m.
To: Openehr-Technical
Subject: Archetypes at OMG




Some of you may be interested to note that a new OMG RfP 'Archetype Modelling 
Language (AML)' will be under discussion at the June OMG 
meeting.


- thomas



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 8390 (20130529) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

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

openEHR Subversion => Github move progress

[Koray Atalag]

Hey that?s really awesome!



Cheers,



-koray



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Roger Erens
Sent: Saturday, 13 April 2013 11:44 a.m.
To: For openEHR technical discussions
Subject: Re: openEHR Subversion => Github move progress



Hey guys,



now that openEHR is on github, have you realised that WE'RE ALL REALLY WRITING 
HISTORY?

See, e.g. http://starlogs.net/#openEHR/gdl-tools

Now that's gonna baffle them at Medinfo!



Cheers,



On Fri, Mar 22, 2013 at 12:13 AM, Thomas Beale mailto:thomas.beale at oceaninformatics.com>> wrote:


The last of what I think are the active Subversion repositories on the old 
openEHR.org server has been converted to GitHub now (the Archetype Editor). 
Repositories which appear to be inactive but could be converted if anyone wants:

*   liu_knowledge_tools (Linkoping has a more recent version of this AFAIK)
*   the original 'knowledge' repository containing a lot of old NHS 
archetypes
*   knowledge_tools_java - not sure about this one.
*   ref_impl_python

For those who have links, checkouts or other pointers to any openEHR SVN 
repositories, please now refer to the Github openEHR 
repositories.

Any questions like 'where did xxx go?', feel free to post them here.

- thomas beale


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





__ Information from ESET NOD32 Antivirus, version of virus signature 
database 8291 (20130503) __



The message was checked by ESET NOD32 Antivirus.



http://www.eset.com

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

translating the openEHR website [From Gunnar Klein]

[Koray Atalag]

Hi,



Pablo I remember having similar discussions within our Localisation Program 
group some time ago. While I tend to agree that dealing with domain names etc. 
is not of high priority right now, nevertheless we need some principles and 
guidance. Obviously this is a major issue we need to be looking at. Anyone's 
free to get domain names but legitimate registration needs some form of 
approval by the main openEHR board or through its proxies - local openEHR 
chapters. We will have to find ways to legitimatise current domain names 
(openEHR.org.es, openEHR.jp 
and openEHR.org.nz etc.) when we have the Program 
going. For those of you not familiar with this initiative: here's the 
Localisation Program Webpage and the 
detailed TOR 
here.



Lots of things can be said but at this stage I think, while the enthusiasm is 
here and given the relaxed period for a month or so, going ahead translating 
the main website, albeit still pretty draft, would be valuable. I think we 
should then look at finding a balance between conformance to the main website 
and local flavour. Of course there will be additional content and that's very 
valuable; even some with IP restrictions (educational materials or artefacts 
belonging to national programmes or projects or commercial entities). I 
strongly think there won't be a one size fits all solution and we'll have to 
improvise ;) The ultimate measure of success is the value it will bring to 
local communities and openEHR at large.



Even if you're living in an English speaking country I encourage you to start 
looking at getting organised locally. We can't expect everything from the 
source but must create capacity and resources in our own communities. Happy new 
year to all and watch this space J



Cheers,



-koray



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Wednesday, 19 December 2012 1:35 p.m.
To: openeh technical
Subject: RE: translating the openEHR website [From Gunnar Klein]



Hi Thomas, we're on early stages of community creation, diffusion of openEHR 
and tools building, right now collisions of domain names are not a priority. 
When the time arrives I think we'll manage :)

--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

  _

Date: Tue, 18 Dec 2012 13:07:05 +
From: thomas.beale at 
oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: translating the openEHR website [From Gunnar Klein]

On 18/12/2012 11:36, pablo pazos wrote:

   Hi Thomas,



   About openEHR.org.es, lets say it's more like a group of interest than an 
oficial branch of the openEHR.org site translated to spanish.



   That's what we have right now, but in the future we can find a way to have 
specific contents generated by us and oficial openEHR contents translated to 
spanish (and meet the requirements (?) to be an official openEHR community 
based on a common language instead of a country/region).



   BTW, openEHR.org.es is for spanish speakers, not a Spain based community.




   I understand the idea, but what would openEHR Spain do if it wants its own 
Spanish local website, to do with Spanish locations, legislation, companies 
etc? It would mean that openEHR.org.es was taken. I don't see any problem right 
now, but it might be worth just thinking about how domains will be organised in 
the future...

   - thomas


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



   __ Information from ESET NOD32 Antivirus, version of virus signature 
database 7814 (20121218) __

   The message was checked by ESET NOD32 Antivirus.

   http://www.eset.com


   __ Information from ESET NOD32 Antivirus, version of virus signature 
database 7843 (20121229) __

   The message was checked by ESET NOD32 Antivirus.

   http://www.eset.com

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

lessons from Intermountain Health, and starting work on openEHR 2.x

[Koray Atalag]

ve interoperability among archetypes, 
created/edited in different editors and due archatype based concept of data 
creation, storage and transport get rid of endless maping, interfacing and data 
mess.

Peter Linhardt
National archetype centre at Slovak university of technology
Bratislava, Slovakia

From: openEHR-technical [mailto:openehr-technical-bounces at 
lists.openehr.org]<mailto:[mailto:openehr-technical-boun...@lists.openehr.org]> 
On Behalf Of Gerard Freriks
Sent: Thursday, October 04, 2012 8:21 AM
To: For openEHR clinical discussions
Cc: For openEHR technical discussions
Subject: Re: lessons from Intermountain Health, and starting work on openEHR 2.x

Dear Koray,

We both agree that the scopes of CEN/ISO 13606 and openEHR differ, as I wrote.
The scope of 13606 is about EHR communication.
That of openEHR is about the implementation in an EHR system.

At present a standard is missing about defining clinical content.
It would be nice, certainly, when both 13606 and openEHR can share that 
standard for clinical content.
In several places the EN13606 Association, whose scope is wider than the 
European context, is actively working towards that goal.
This single approach for a standard for clinical content is very important when 
we want generic semantic interoperability.
This is the reason why components for a potential standard on archetype 
production are developed inside the Association.
A standard that defines the intersections with: coding systems, ontologies, 
other CEN/ISO standards like System of Concepts for Continuity of Care and the 
Health Information Services Architecture.
All resulting in one basic generic pattern, for all artefacts, that by 
specialisation is able to be used for all kinds of archetypes.
A basis pattern that in more detail allows the definition of more nuances than 
the archetypes we know, so far.
A basic pattern that brings features closer to actual use such as negation, 
semantic ordinals (with inclusion and exclusion criteria), better integration 
with clinical workflow, ontological reasoning over structure and codes, etc.

The EN13606 Association of implementors of the 13606 standard has considerable 
experience in the production of applications based on this standard.
When I look into future needs and developments around the use of coding systems 
and ontologies, I see state of the art developments among the members of the 
Association.

W3C is a good example. indeed.
As far as I know W3C does not prescribes how to implement their standards in 
systems.
This is the responsibility of the industry in all circumstances.


Gerard Freriks
+31 620347088
gfrer at luna.nl<mailto:gfrer at luna.nl>



On 4 Oct 2012, at 02:02, Koray Atalag wrote:

Hi Gerard,
I think getting the content model is absolutely right - no one can argue
But with due respect I disagree with you about the difference. I seriously 
think standards defining clinical content should converge (not even harmonise).
I had the privilege of spending some time with Ed Hammond in NZ and was 
convinced that this is what is needed. Mappings are different and certainly a 
blackhole.
That said EN13606 Association's mission and role is paramount in terms of 
contextualising "exchange" within the European context.

We chose to use openEHR for defining the Interoperability standards in New 
Zealand as we are very mindful of the fact that this formalism has been defined 
and carried on for many years by this group; and it IS naturally the leading 
edge with proven track in implementation (one of which is my own work). I think 
W3C is a good example of how important it is to have a single approach in 
contrast to the situation in health IT. These might sound a bit strong but it 
is what I believe. I acknowledge lack of organisational capacity and skills in 
past though.

Cheers,

-koray


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121007/7db29fd4/attachment-0001.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Koray Atalag]

Hi Gerard,
I think getting the content model is absolutely right - no one can argue
But with due respect I disagree with you about the difference. I seriously 
think standards defining clinical content should converge (not even harmonise).
I had the privilege of spending some time with Ed Hammond in NZ and was 
convinced that this is what is needed. Mappings are different and certainly a 
blackhole.
That said EN13606 Association's mission and role is paramount in terms of 
contextualising "exchange" within the European context.

We chose to use openEHR for defining the Interoperability standards in New 
Zealand as we are very mindful of the fact that this formalism has been defined 
and carried on for many years by this group; and it IS naturally the leading 
edge with proven track in implementation (one of which is my own work). I think 
W3C is a good example of how important it is to have a single approach in 
contrast to the situation in health IT. These might sound a bit strong but it 
is what I believe. I acknowledge lack of organisational capacity and skills in 
past though.

Cheers,

-koray

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Gerard Freriks
Sent: Thursday, 4 October 2012 11:26 a.m.
To: For openEHR clinical discussions
Cc: Openehr-Technical
Subject: Re: lessons from Intermountain Health, and starting work on openEHR 2.x

I just care about getting one model

In the case of 13606 one good model that describes a generic interface for EHR 
communication, also, for communication with other proprietary EHR solutions.
In the case of openEHR one good model that describes one particular 
implementation of an EHR-system.

This difference is something the EN1366 Association cares about.

Gerard Freriks

EN13606 Association
p/a Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

M:+31 620347088
E: gerard.freriks at 
EN13606.org
W:   http:www.en13606.org

On 4 Oct 2012, at 00:02, Thomas Beale wrote:


On 13/09/2012 10:15, David Moner wrote:
Hi,
2012/9/13 Erik Sundvall mailto:erik.sundvall at 
liu.se>>
It would be great if e.g most of the future ISO 13606 version could be a true 
subset of openEHR instead of the current confusing situation.

This is something I discussed with Thomas some time ago, it would be one of the 
best harmonisation solutions, but probably with a slightly different 
interpretation. Since 13606 has more generic classes (eg. the generic ENTRY can 
represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead of 
13606 being a subset of openEHR I think that openEHR should be a specialized 
model of 13606. Obviously this would require a deep analysis and changes of the 
models, but that could be the idea.

I don't care about the linguistics of subset / specialisation etc, I just care 
about getting one model

- thomas




Gerard Freriks
+31 620347088
gfrer at luna.nl




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

HL7 opens up

[Koray Atalag]

So then all they have to do is to create as good stuff as openEHR does ha ;)
Don't tell this - I'm a board member of HL7 NZ :)
I'd like to see this as a big step towards 'consolidation' of eHealth standards 
(heard from Ed when he was here and agree)...I don't believe in harmonisation 
as neither do I support the idea of mappings etc.
I can't think of any better global platform to embrace other cool stuff 
required for 'healthy' working of systems - why not openEHR?

Cheers,

-koray


-Original Message-
From: openehr-technical-bounces at lists.openehr.org 
[mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Bert Verhees
Sent: Wednesday, 5 September 2012 9:44 a.m.
To: For openEHR technical discussions
Subject: Re: HL7 opens up

On 04-09-12 20:06, Diego Bosc? wrote:
> The big question is, how does it affect us?

HL7 is primary a way of messaging. In the Netherlands HL7 is very important, as 
message format. All (I mean ALL) the underlying systems which create the 
messages have legacy datamodel-storage.
There is no such thing as an HL7v3 storage system on the dutch market.

Also an OpenEHR system can create HL7 messages, especially those 
message-definitions which are created for the Netherlands, which are created 
with focus on interoperability, to get all the legacy-systems possible to join.

So, I see no big change for the Dutch market. Anyway, costs were never an issue.

HL7 is also a storage concept, and I have been to some HL7-meetings, where they 
discuss these kind of things.

Without any hesitation, I saw people admiring HL7 systems which needed
50 to 100 tables to store their thing, and which auto-created SQL-statements 
from 250!!! lines to query the thing.

That is not my way to go, especially if the purpose is interoperability by 
creating the specially defined RMIM-messages, which are written with focus on 
legacy to incorporate in the messaging-EPD.

As I know the market in the Netherlands, I know it well, my expectation is that 
legacy will dominate the progression next ten years, or even longer.

We even have systems which are just five years ago ported to 32 bits Windows 
(from 16 bits), and still use an old fashioned API-based database. This is one 
of the richest healthcare-environments in the world.

That is what is going on.

So HL7 for free, nice, we can conform to the message-definitions for free, and 
if system-builders succeed in free themselves from their academic way of 
software-constructing and legacy and can use HL7 constructs to store their data 
quick, they have an easy way for creating the messages.

(Hey HL7 folks, the secret for you is XPath, oops, now I gave away the
secret.)

Fine. Let a thousand flowers bloom.

When we are confident in our own software, there is nothing to fear from HL7.

That is my opinion.

kind regards
Bert Verhees



>
> 2012/9/4 Timothy Cook :
>> Finally:
>> http://www.hl7.org/about/faqs/FreeIP.cfm
>>
>>
>>
>> --
>> 
>> Timothy Cook, MSc   +55 21 94711995
>> MLHIM http://www.mlhim.org
>> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
>> Skype ID == timothy.cook
>> Academic.Edu Profile: http://uff.academia.edu/TimothyCook
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.ope
>> nehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.org
>


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


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 7446 (20120904) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 7446 (20120904) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Constraints on displaying

[Koray Atalag]

Hi, 

As I understand this is an issue related with semantics rather than 
presentation as it reads. Therefore I'd say you'd define the rule in 
Invariant/Rules section of the Archetype (I might be wrong with the naming 
though).

But as we go into real implementations some dodgy things start to come out; 
that you can't always separate semantics of information from presentation. For 
the latter GUI Directives, a new shadow model if you like, will solve the 
problem. However how to solve the issue with the semantics and link 
presentation to it consistently is a difficult question. That's why I still 
believe (sorry purists will hate me but), as they do in CDA - the way clinical 
information presentation has also a meaning in real practice, and we should be 
expressing it within Templates if not Archetypes. 

Thanks for raising this issue, so let the discussions begin ;)

Cheers,

-koray

-Original Message-
From: openehr-technical-bounces at lists.openehr.org 
[mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Diego Bosc?
Sent: Friday, 20 July 2012 7:47 a.m.
To: For openEHR technical discussions
Subject: Re: Constraints on displaying

I think she is referring to something like "if patient is male then obstetrics 
field should be null", and those are created as invariants

2012/7/19 pablo pazos :
> Hi Leysan,
>
> Archetypes are for content definition, not to define rules on field 
> displaying on GUI.
> That should be part of a GUI directive, maybe inside a GUI Template.
> http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualizat
> ion+templates
>
> --
> Kind regards,
> Ing. Pablo Pazos Guti?rrez
> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
> Blog: http://informatica-medica.blogspot.com/
> Twitter: http://twitter.com/ppazos
>
> 
> Date: Thu, 19 Jul 2012 16:50:41 +0300
> Subject: Constraints on displaying
> From: pirogmanic at gmail.com
> To: openehr-technical at lists.openehr.org
>
>
> Hello!
>
>
>
> Could you tell me, please, how can I constrain the archetype 
> displaying (or only the one field of the archetype), according to the 
> sex (age) of a patient?
>
> Thank you,
>
> Leysan
>
>
>
>
> ___ openEHR-technical 
> mailing list openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.org

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

Tooling support for ADL1.5 and beyond

[Koray Atalag]

Hi All,



Sorry if this has been addressed before but I was wondering where we are at the 
moment wrt to developing clinically usable tooling for ADL 1.5 etc. I'm 
wondering if this is in the roadmap of other groups, not just Ocean?



Cheers,



-koray



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

Are you doing an academic project using openEHR?

[Koray Atalag]

Hi Tom, we're here:  http://gastros.codeplex.com/



Country: New Zealand



Institution: The University of Auckland, National Institute for Health 
Innovation



Team: Koray Atalag, Hong Yul Yang



Project Description

GastrOS is an endoscopic reporting application based on open standards: openEHR 
and MST. GUI is driven by Archetypes/Templates. It is part of our research at 
the University of Auckland to investigate software maintainability and 
interoperability.

Uses openEHR.Net on CodePlex



Cheers,



-koray



From: openehr-technical-bounces at lists.openehr.org 
[mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale
Sent: Monday, 19 March 2012 3:30 a.m.
To: Openehr-Technical
Subject: Are you doing an academic project using openEHR?




The academic 
projects<http://www.openehr.org/shared-resources/usage/academic.html> page on 
the website lists currently known projects. I am sure that there are more 
today. Please let us know if you have a project, and the details of it, we will 
post it on this page.

- thomas beale


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6991 (20120323) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/d8abbdb7/attachment-0001.html>

Meaningful Use and Beyond - O'Reilly press - errata

[Koray Atalag]

Hi Fred,

Apropos to Tom I'd say openEHR is also equally to do with software 
maintainability; thanks to the dual or multi-level modelling and model driven 
development. This is my main research area as well as open source software. I 
agree with Tom's comments that being open source by itself is not enough (for 
any software quality aspect I believe) and must be accompanied with open 
standards. If I was asked to explain openEHR to my mother I'd probably say: 'it 
is about getting information right in healthcare'. I usually find this 
statement as the starting point when talking to other audiences such as 
computer scientists and developers. Perhaps you'll find useful as well.

Cheers,

-koray


From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of fred trotter
Sent: Saturday, 18 February 2012 1:27 p.m.
To: For openEHR technical discussions
Subject: Re: Meaningful Use and Beyond - O'Reilly press - errata

Thomas,
 This is quit usable critique and I will certainly draw from it in 
future revisions of the work.

You make the argument that OpenEHR is primarily for interoperability, and I can 
accept that fundamental argument. It is difficult to swallow however, when I 
hear the HL7 v3 wonks talking about how HL7 RIM is the solution to semantic 
interoperability. Are they confused or are you confused, because you are saying 
basically the same thing. From my perspective as in implementer it looks 
awefully like a blueray vs HDDVD war and it looks like OpenEHR is losing. But 
at the same time I keep hearing that HL7 RIM is "compatible" with and might be 
"merged" with HL7 RIM.

Very confusing, and I have yet to see something compelling that can be done in 
OpenEHR that cannot be done with HL7 RIM.

Having said that, HL7 RIM is a proprietary ontology/model and OpenEHR, is not. 
That gives OpenEHR some usefulness even as an alternative model. Is that where 
I should see the value? Here is an information model that delivers semantic 
interoperability but is not proprietary?


On Fri, Feb 17, 2012 at 6:15 AM, Thomas Beale mailto:thomas.beale at oceaninformatics.com>> wrote:

Hi Fred,

I think you are missing the point. The key thing we are working on in openEHR 
is interoperability, not open source. Open source health applications have 
historically not made any difference to interoperability, intelligent computing 
or anything else - they are the same as closed source systems that don't do any 
of these things. This is not to say that they aren't better quality software / 
solutions in other ways - some are very nice. But in general they have the same 
proprietary data formats and service interfaces as commercial solutions (making 
such definitions openly available doesn't change anything).

Solving interoperability and intelligence in e-health (as for other domains) is 
very hard indeed, and solutions based on simple approaches only have marginal 
benefit. What matters to clinical people and actual health delivery is 
interoperability, regardless of closed or open source: open standardised (= 
widely agreed) information models, service interfaces and knowledge formalisms. 
Of course open source, done the right way does have a lot to offer, and can 
make the economics better, but it doesn't specifically address the 
interoperability problem.

What I think you will see in the future is intelligent health computing 
platforms based on openEHR, or something like it (as you noted, Tolven also 
does not have much penetration today, but it also is a sophisticated solution 
that takes semantic interoperability seriously). See the CIMI 
forum to get some idea 
of the international backing for knowledge-driven architecture. Without these 
kind of model-driven architectures, semantic interoperability will remain a 
dream, as will any serious industry around decision support, business 
intelligence and data-based medical research, and any other application wanting 
to use computable patient-centred health data. Because of the time it has taken 
to mature the openEHR - and other related, and even competing - health 
computing platforms, solutions based on these platforms are only just starting 
to make serious inroads.

I have no problem with your view of openEHR in terms of limited penetration 
(today), but what I think would be a little more positive would be for the open 
source sector to actually take part in solving interoperability, rather than 
continuing to add to the problem. There are real synergies to be explored. Much 
of the new work in openEHR and related architectures is coming out open source. 
It would be great if existing open source health application developers were to 
get involved - e.g. by working with us and others (e.g. HL7 HSSP, IHE etc) on 
e-health service 
models. We on 
the other hand have a lot to learn about e-

openEHR - Persistence of Data

[Koray Atalag]

I remember a Honours or Master's thesis on openEHR persistence...I think Heath 
was involved. Heath is that publicly available?



Cheers,



-koray



From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of M?rcio Costa
Sent: Saturday, 18 February 2012 10:36 a.m.
To: For openEHR technical discussions
Subject: Re: openEHR - Persistence of Data



Do Anyone knows about some papers of persistent storing?



att,


M?rcio Costa
B.Sc. in Computer Science @ Cin/UFPE
M.Sc. Candidate in Computer Science @ CIn/UFPE
MSN: mdckoury at gmail.com




Em 17 de fevereiro de 2012 17:59, M?rcio Costa mailto:mdckoury at gmail.com>> escreveu:

i would like to thank everyone for the information and attention.



i'm trying to do a review about this subject to start my research, but i will 
do something to analyse the best way to model and persist this kind of data.



Best Regards,



M?rcio Costa
B.Sc. in Computer Science @ Cin/UFPE
M.Sc. Candidate in Computer Science @ CIn/UFPE
MSN: mdckoury at gmail.com




2012/2/17 pablo pazos mailto:pazospablo at 
hotmail.com>>

Hi Erik, you are right, the uglyness depends on 1. the queries you want to 
execute and 2. the programmer background.



For 1. the "common" queries like get all records for this patient in this time 
window, are not that ugly, but more complex queries could be.

For 2. for a XML guy, writing xPath based queries is ok, but for a SQL is a 
pain in the a55.

:D

I'm hoping to see that paper on AQL->xQuery soon!



I totally agree that inside the system maybe you don't need a complete RM 
structure to handle data instances, but for the service layer (sharing 
information with other systems) this is a must.



--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

> Date: Fri, 17 Feb 2012 16:21:29 +0100
> Subject: Re: openEHR - Persistence of Data
> From: erik.sundvall at liu.se
> To: openehr-technical at openehr.org


>
> Hi!
>
> On Thu, Feb 16, 2012 at 23:26, pablo pazos  hotmail.com> wrote:
> > Other models I didn't try yet are Object Oriented DBs and
> > Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs
> > are a good option, fast for store highly hierarchical structures,
> > but you need to write some ugly queries if you want your data back :D
>
> Not necessarily that ugly... we curently auto-convert AQL to XQuery
> and execute towards an XML database. Those queries are very readable.
>
> Then the question is what kind of client system you are aiming at. For
> some use cases you don't really need to map things back to
> openEHR-RM-objects, in web browser based GUIs for example you can keep
> treating the data as documents, document fragments, fragment lists
> etc. and use DOM manipulations, jQuery or similar approaches for most
> data manipulation needs.
>
> Good luck with your work M?rcio and please keep us informed!
>
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se 
> http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
>
> ___
> 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







__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6898 (20120220) __



The message was checked by ESET NOD32 Antivirus.



http://www.eset.com

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

openEHR mailing lists - moving

[Koray Atalag]

Hi Tom,



I used SourceForge before to host projects (yes that's correct not just 
software development but collaborative project sites) in past which offers for 
free lists and many more, such as Web pages, SVN/Mercurial, blog and Wiki and 
many more. I reckon the licensing might be an issue for non FOSS projects but I 
believe in the case of openEHR that's a non issue?? I must admit the SVN is not 
as fast and there's limited administration capability but hey it's still great 
value for nothing. Plus the platform also allows for 'donations' which I think 
might create few bucks to look after things like administration etc. until an 
appropriate funding mechanism becomes available.



Cheers,



-koray



From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 20 January 2012 1:31 a.m.
To: Openehr-Technical; For openEHR clinical discussions
Subject: openEHR mailing lists - moving




there is an urgent need to move the openEHR community mailing lists from their 
current location at CHIME, UCL to another location. We have now researched 
commercial options for handling mailman lists, and have found a number of 
suitable providers. In all cases, we would move the archives of all lists, as 
well as automatically resubscribing all members of all lists.

For most of these offerings, it looks as if we will have to change list 
address, i.e. openehr-technical at openehr.org will become openehr-technical at 
lists.openehr.org.

The consequences of this are (assuming the automatic resubscription):

*   taking part in new discussion threads should work normally
*   responding to existing threads, containing the original list address, 
will probably not work (unless we make redirection of mail to xxx at 
openehr.org => xxx at lists.openehr.org work)
*   any saved copies of openehr list addresses will be wrong. Usually 
people don't rely on such things for mailing lists, so this should not be a big 
problem.

for the moment at least, the lists.openehr.org and openehr.org domains will be 
in different places.

The solution above appears to be the only one available at the moment, and 
costs money, unless an academic institution in the openEHR network wants to 
offer to host mailing lists.

This move is part of a larger move of openEHR's online presence out of UCL. It 
appears that for most things (SVN, Jira, Atlassian, website), paid online 
hosting will be the way to go, unless there are academic institutions 
interested in taking on the job. These changes will mean a) some (hopefully 
small) upheavals in the user experience, and b) some costs that need to be 
covered. I would think the board would be interested in any help on the second 
score.

- thomas beale



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6808 (20120119) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6811 (20120120) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

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

pass_through attribute in ADL 1.5

[Koray Atalag]

Hi Tom and Diego,



Short response is yes this is a better way of hardwiring a pure presentation 
related attribute into Archetypes which are supposed to deal with meta-data, 
structure and semantics of information only. The ideal solution would be to 
have an accompanying (but separate) layer of model responsible for GUI stuff.



Our experience is that there are three types of such 'things':

1)  Pure GUI related (such as passthrough or depicting a particular GUI 
widget, style etc.)

2)  Assumed (e.g. to render a textbox for DV_TEXT or draw a frame/indend 
children nodes under CLUSTER)

3)  Mixed - where it is not easy to separate presentation from semantics.



Regarding (3), for example we have a GUI Directive called isCoreConcept (which 
we were inspired by the openSDE project by Astrid van Ginneken) which when 
modelling clinical findings and causes GUI generator to put a four state 
checkbox (null, present, absent, unknown). This actually applies to any 'thing' 
which we can also talk about its absence. This semantics implies to show or 
hide all of its children based on its presence (or absence).



I think we can use one Archetype attribute (to depict the semantics that this 
is a clinical finding or perhaps a new class of its own (e.g. 
DV_CLINICAL_FINDING) and perhaps separate GUI directives (or make it an assumed 
behaviour when that semantic attribute is set) create this appearance and 
behaviour.



Not so sure if I can show you other clear examples (other than core concept) at 
this stage but I suspect there are others.



Oh and we have also identified a whole new territory which we call 'information 
axes' and 'semantic equivalence' ;) This also has to do with both semantics and 
presentation I believe. Think about capturing (and modelling archetypes)  a 
clinical statement as:



"Polyps were present in sigmoid colon and rectum and ulceration was seen in 
rectum."

"In rectum polyps and ulceration were seen and ulceration was present in 
sigmoid colon"



These are equivalent but how to model the archetypes; e.g. finding or site 
oriented will depend on modelling best practices and use cases. Rule of thumb 
is to design archetypes as close to screen representation as possible (hence 
the clinicians thinking). We must be able to depict in archetypes and/or 
presentation model that alternative representations exist and how to construct 
these. SNOMED CTs normal/canonical forms is pretty related with this but then 
the semantics is hardcoded into the SCT axes.



My 2 cents



Cheers,



-koray



From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: Tuesday, 10 January 2012 8:04 a.m.
To: openehr-technical at openehr.org
Subject: Re: pass_through attribute in ADL 1.5



On 05/01/2012 08:54, Diego Bosc? wrote:

Put a couple of comments on the wiki, but I think it is a thing that
should be discussed on the list.
In ADL 1.5 a flag 'pass_through'  was added. Its definition is 'Allows
nodes required for structuring data but otherwise redundant for screen
display and reporting to be detected by rendering software'. So now we
have a GUI directive on the ADL. Shouldn't this be a part of the
reference model information (if it is never supposed to be displayed)
or part of a 'visualization template' (another different level).
I would say that more information about visualization will be needed,
and having visualization information separated between two different
places feels like a bad design move.


In general I am inclined to agree, and I have to say I have been in two minds 
about having this attribute in there. I am convinced by clinical modellers who 
say that something is needed to control interior tree nodes not appearing on 
the GUI (indeed, it is visual pollution). And - even if the template were being 
used to build a message definition (generated XSD or similar), and the data 
were processed into some report or other output, this attribute would be 
respected (technically, this is still 'user interface').

I know the passthrough attribute is used often from the current .oet template 
usage, so we need a way of dealing with the requirement. If we take it out, and 
say it is a GUI directive, the problem is we currently have no formal framework 
for that yet. Maybe the lesser of two evils is to do what Koray (I think?) 
said, and make it a special kind of annotation. I have implemented annotations 
in ADL/AOM 1.5, and they work nicely. We need to agree on some kind of standard 
representation, e.g.



I originally didn't like this approach (I still don't really) but we have to be 
realistic and it's not the end of the world to bootstrap like this. As you can 
see it is 'soft programming', so error-prone, but it can obviously be made to 
work, and isn't hard to implement. However, now rendering software has to know 
to look for "ui" annotations and do sensible things with them.

thoughts?

- thomas

open source openEHR-related EHR systems; How do you want to be cited...

[Koray Atalag]

Hi Eric, we started GastrOS in SourceForge but then used CodePlex (don't ask me 
why!).

The correct URL is: http://gastros.codeplex.com



Happy 2012 to you all J



Cheers,



-koray



From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Erik Sundvall
Sent: Thursday, 5 January 2012 5:59 a.m.
To: For openEHR technical discussions; Luciana Tricai Cavalini
Subject: Re: open source openEHR-related EHR systems; How do you want to be 
cited...



Hi!

Thanks for nice replies, hints and suggestions regarding open source archetype 
based EHR systems. Is any relevant open source project left out, misquoted or 
misunderstood in the following formulation:

...and several open source alternatives that explore different approaches to 
implement archetype based EHR systems are available. Examples (programming 
language in parenthesis) are:
? EHRflex [EHRflex], http://ehrflex.sourceforge.net/ (Java)
? GastrOS [GastrOS], http://sourceforge.net/projects/gastros/ (.NET+C#)
? openEHRgen, http://code.google.com/p/open-ehr-gen-framework/ 
(Groovy+Java)
? Opereffa, http://opereffa.chime.ucl.ac.uk/ (Java)
Also, implementations in Ruby [oe-ruby], 
http://openehr.jp/projects/show/ref-impl-ruby, and Python [oship] 
http://www.oship.org/ provide components for archetype-based EHR systems.

With a reference list along the lines of:



   *[EHRflex] Anton Brass, David Moner, Claudia Hildebrand, Montserrat 
Robles Standardized and flexible health data Management with an archetype 
driven EHR system (EHRflex). EFMI Special Topic Conference 2010 Seamless care - 
Safe care: The Challenges of Interoperability and Patient Safety in Health 
Care. Proceedings of the EFMI Special Topic Conference, pp. 212-218. IOS Press 
BV, Amsterdam. ISBN: 978-1-60750-562-4, 2010.
   *[GastrOS] Atalag K, Yang HY, Tempero E, Warren J. Model Driven 
Development of Clinical Information Systems using openEHR. Stud Health Technol 
Inform 2011;169:849-853.
   *[oe-ruby] Shinji Kobayashi and Akimichi Tatsukawa. Ruby Implementation 
of the openEHR specifications. Journal of Advanced Computational Intelligence 
and Intelligent Informatics, in press
   *[oship]  Luciana T Cavalini and Timothy W. Cook. Health Informatics: 
The Relevance of Open Source and Multilevel Modeling. Proceedings of Open 
Source Systems: Grounding Research (OSS 2011) Pages 338-347. Springer 2011

   Please report any misunderstandings or comments to me or to the list.



   Best regards,
   Erik Sundvall
   erik.sundvall at liu.se 
http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

   On Thu, Dec 8, 2011 at 10:02, Erik Sundvall mailto:erik.sundvall at liu.se>> wrote:
   > Hi!
   >
   > We now getting the LiU EEE paper "Applying REST Architecture to
   > Archetype-based EHR systems" (by Erik Sundvall, Mikael Nystr?m, Daniel
   > Karlsson, Martin Eneling, Rong Chen and  H?kan ?rman) finished for
   > submission, and in a background passage we mention other openEHR based EHR
   > systems (where you can enter and query pateint data) that are open source:
   >
   > "...the situation has changed to the better and more open source
   > alternatives [opereffa, openEHRgen, GastrOS, oship/MLHIM] that explores
   > different approaches to implement openEHR systems..."
   >
   > Now, if you are involved one of the mentioned systems [opereffa, 
openEHRgen,
   > GastrOS, oship/MLHIM], what is your favorite or most up to date paper or
   > other reference that you think describes your system best and that you 
would
   > prefer that people considered citing in academic papers?
   >
   > If you feel that we have missed listing an open source openEHR system with
   > non-viral permissive licence, then please enlighten us!



   __ Information from ESET NOD32 Antivirus, version of virus signature 
database 6771 (20120105) __



   The message was checked by ESET NOD32 Antivirus.



   http://www.eset.com

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

13606 revisited - list proposal

[Koray Atalag]

+1

BTW in an ideal world the 13606-openEHR divergence shouldn't have happened in 
first place. I seriously think we can't afford to fall apart and go our own 
ways. But never mind...

-koray

-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Adolfo Mu?oz Carrero
Sent: Thursday, 15 December 2011 11:14 p.m.
To: openehr-technical at openehr.org
Subject: Re: 13606 revisited - list proposal

Dear Thomas,

I also think it's a good idea.

Regards,

 Adolfo Mu?oz

El 15/12/2011 11:04, Rong Chen escribi?:
> Great idea, Thomas!
> /Rong
>
> On 15 December 2011 10:29, Isabel Rom?n Mart?nez  
> wrote:
>> Dear Thomas,
>> I think it is a good idea.
>> Best Regards,
>> Isabel
>>
>> El 15/12/2011 10:01, Marcelo Rodrigues dos Santos escribi?:
>>
>> Dear Thomas,
>>
>> The creation of this list will be an excellent contribution to
>> promote the harmonization process. In my opinion the alignment of
>> these two initiatives is a concrete step to achieve interoperability among 
>> EHR systems.
>>
>> Best regards,
>>
>> Marcelo
>>
>> 2011/12/15 Seref Arikan
>>
>> Hi Tom,
>> Yes, such a list would be good.
>>
>> Regards
>> Seref
>>
>>
>>
>> On Thu, Dec 15, 2011 at 12:49 AM, Thomas Beale
>>   wrote:
>>
>>
>> At the CIMI meeting last week and elsewhere, I have noticed a lot of
>> interest in the ISO 13606 2012 revision, specifically in a) whether
>> the openEHR and 13606 reference models can be brought together for
>> part 1 of the revision and b) in finalising ADL/AOM 1.5 for providing
>> a new snapshot to ISO for part 2.
>>
>> It seems to me that it would be useful to have a dedicated place to
>> discuss this, so I would like to propose a new mailing list,
>> 13606-alignment at openehr.org
>>
>> Does this seem like a useful idea?
>>
>> - thomas beale
>>
>> ___
>> 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
>>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


--
Adolfo Mu?oz Carrero
Instituto de Salud Carlos III
Unidad de Investigaci?n en Telemedicina y eSalud Avda. Monforte de Lemos 5 - 
Pabell?n 14
28029 Madrid
Tfno: +34 918222182
FAX: +34 913877567


* AVISO LEGAL *
Este mensaje electr?nico est? dirigido exclusivamente a sus destinatarios,
pudiendo contener documentos anexos de car?cter privado y confidencial.
Si por error, ha recibido este mensaje y no se encuentra entre los
destinatarios, por favor, no use, informe, distribuya, imprima o copie su
contenido por ning?n medio. Le rogamos lo comunique al remitente y borre
completamente el mensaje y sus anexos. El Instituto de Salud Carlos III no
asume ning?n tipo de responsabilidad legal por el contenido de este mensaje
cuando no responda a las funciones atribuidas al remitente del mismo por la
normativa vigente.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6712 (20111214) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6716 (20111216) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6716 (20111216) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

open source openEHR-related EHR systems; How do you want to be cited...

[Koray Atalag]

Hi Erik, I suggest using this one:

1.

Atalag K, Yang HY, Tempero E, Warren J. Model Driven Development of Clinical 
Information Systems using openEHR. Stud Health Technol Inform 
2011;169:849-853.[cited 2011 Oct 27 ]



Many thanks!



-koray



From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of pablo pazos
Sent: Monday, 12 December 2011 4:39 p.m.
To: openehr technical
Subject: RE: open source openEHR-related EHR systems; How do you want to be 
cited...



Hi Erik,



I don't have a formal paper on Open EHRGen, but I have a paper of the 
application of the framework to model a trauma EHR: 
http://www.slideshare.net/pablitox/proyecto-traumagen-cais-jaiio-2010



You can site this work, ormaybe just put a reference to the project page: 
http://code.google.com/p/open-ehr-gen-framework/



thanks a lot. (please send me a copy of the paper when available)

--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

  _

Date: Thu, 8 Dec 2011 10:02:33 +0100
Subject: open source openEHR-related EHR systems; How do you want to be cited...
From: erik.sundvall at liu.se
To: openehr-technical at openehr.org

Hi!



We now getting the LiU EEE paper "Applying REST Architecture to Archetype-based 
EHR systems" (by Erik Sundvall, Mikael Nystr?m, Daniel Karlsson, Martin 
Eneling, Rong Chen and  H?kan ?rman) finished for submission, and in a 
background passage we mention other openEHR based EHR systems (where you can 
enter and query pateint data) that are open source:



"...the situation has changed to the better and more open source alternatives 
[opereffa, openEHRgen, GastrOS, oship/MLHIM] that explores different approaches 
to implement openEHR systems..."



Now, if you are involved one of the mentioned systems [opereffa, openEHRgen, 
GastrOS, oship/MLHIM], what is your favorite or most up to date paper or other 
reference that you think describes your system best and that you would prefer 
that people considered citing in academic papers?



If you feel that we have missed listing an open source openEHR system with 
non-viral permissive licence, then please enlighten us!


Best regards,
Erik Sundvall
erik.sundvall at liu.se 
http://www.imt.liu.se/~erisu/  Tel: +46-13-286733


___ openEHR-technical mailing list 
openEHR-technical at openehr.org 
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6703 (20111212) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

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

Could YAML replace dADL as human readable AOM serialization format?

[Koray Atalag]

Oh, just my personal thoughts without any sanity check - should have read the 
whole thread first! My reaction was just to what was written in the subject 
line of the thread and after reading Seref's comments about the need to focus 
on outstanding/high priority issues. Sorry if I have offended - I can't 
possibly be against free discussions here - even the most blue sky ones which I 
seldom broadcast myself ;)

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Erik Sundvall
Sent: Wednesday, 7 December 2011 11:30 p.m.
To: For openEHR technical discussions
Subject: Re: Could YAML replace dADL as human readable AOM serialization format?

Oh sigh...

Trying to be open minded, thinking a few steps ahead, sharing thoughts and 
regularly reevaluating design decisions does not seem to be appreciated by all 
on this list.

Perhaps we need to mark some discussions or sections with...
[Warning: may contain new thoughts]
...so that those of us that enjoy such discussions may continue to have them 
and those that get distracted by them or can't stand them could filter out 
those parts.

On Tue, Dec 6, 2011 at 22:23, Koray Atalag mailto:k.atalag at auckland.ac.nz>> wrote:
Yeah I was also wondering what is the driver/motivation/aspiration behind using 
JSON, YAML etc. instead of good old ADL?

Good old which ADL? Please go back in the thread and note the difference 
between dADL and cADL in the reasoning, dADL is a reinvention of the wheel 
(object tree serialization) cADL is an optimized DSL that I have not seen any 
obvious widespread alternative to if brevity and readability is sought for.

Regarding the motivation you ask for, I would recommend going back in the 
thread again to the first message...
http://www.openehr.org/mailarchives/openehr-technical/msg06186.html
...under the boldface heading "Motivation:", that you may have missed, and read 
the three bullet points. You may not agree but that and the rest of this 
current message might reduce your wondering about the discussion origins.

I also think that we as a community should look at getting more organised and 
get our efforts in tune

Yes, a bit of diversity is good in order to best explore design space, but 
duplicating work is a waste of time.
If we are allowed to discuss future-directed thoughts on this list (without 
people getting too upset) that may also help us tune our efforts. If we must 
implement first and then discuss it will be a lot harder to avoid duplication 
of work.

as I know that quite interesting and though times are about to come...

Are you referring to the CIMI-discusions or is it a general observation about 
how the future usually is :-)

Regarding CIMI I think it is valuable to try to look upon openEHR with the eyes 
of newcomers. If there is unnecessary legacy in models or formats that we don't 
easily see because we have gotten used to it, then now is a good time to try 
reducing it while the amount of patient data using openEHR is limited. It will 
be harder to change things later. Getting the template formalism integrated 
with the AOM 1.5 was great in this sense, and so is Tom's experimentation with 
RM 2.0 constructs that may reduce the ITEM_STRUCTURE hierarchy.

From: ... On Behalf Of Stef Verlinden
+1

+/- infinity
 Yay, I love flame wars :-)

On Tue, Dec 6, 2011 at 12:44, Seref Arikan mailto:serefarikan at kurumsalteknoloji.com>> wrote:
Given this, if you or someone else thinks that YAML can be an alternative to 
dADL, there is nothing stopping anyone than implementing it and using it. 
Absolutely nothing.

Do you assume that if somebody is talking about a subject, then they can't 
possibly be in the middle of implementing it and wanting to share thoughts at 
an early stage? Please try to be a bit more open minded, I did not ask you to 
be the first to implement YAML support. You are not the the only one 
implementing openEHR stuff, but I will admit that you deserve credit for, and 
are great at "release early, release often" and I am not (yet).

Thomas is heroically responding to all queries without judgement...

I think that is an unfair description of Tom's judgment.

I have a feeling that all these discussions about if this or that could replace 
dADL are too hypothetical. Most of the time they are academic discussions. 
There is nothing wrong with academic discussions, I am doing a PhD here, but if 
the openEHR community is spending its time and resources for academic 
discussions which do not necessarily connect to real life implementations in 
the near term, then I think we have a problem.

So if something is not on your personal implementation agenda in near time, 
then it is "academic" and a waste of resources since it can not possibly be on 
the implementation agenda of somebody else... :-)

The reason I started looking into both JSON and YAML is that th

Could YAML replace dADL as human readable AOM serialization format?

[Koray Atalag]

Yeah I was also wondering what is the driver/motivation/aspiration behind using 
JSON, YAML etc. instead of good old ADL?
Is this to do with making openEHR easier to digest for the 'traditional' IT 
community because perhaps they don't want to let go everything at once and 
leverage some existing skills like these? I also think that we as a community 
should look at getting more organised and get our efforts in tune as I know 
that quite interesting and though times are about to come...

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Stef Verlinden
Sent: Wednesday, 7 December 2011 1:01 a.m.
To: For openEHR technical discussions
Subject: Re: Could YAML replace dADL as human readable AOM serialization format?

+1

Cheers,

Stef


Op 6 dec. 2011, om 12:44 heeft Seref Arikan het volgende geschreven:



Please do not get me wrong, all the discussion we are having here is useful, it 
is just that in my humble opinion, some discussions are more useful than others 
if this standard into which I am heavily investing is to go forward.

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

Multiple archetypes in a single concept as a way to create an archetype collaborative

[Koray Atalag]

Hi there,

Which archetypes to put on CKM and now has been an issue in my work as 
well...Some of you might have gotten sick of hearing this again but I'm dealing 
with very detailed (and specific) archetypes covering digestive endoscopy. 
Since they are now around 10 years old (!) and quite mature for our purpose 
unfortunately have little use for the rest of you. The main usage of CKM today 
is to share the common denominators for achieving a reasonable level of 
interoperability at a minimal cost. Don't forget that CKM work is not a funded 
project and people are doing it voluntarily (well perhaps has some fringe 
benefits but...).

So to cut it short we previously discussed the idea of having a 'production' 
space on CKM and also 'specialised' workspaces. Also a 'sandpit' workspace will 
be very very useful.

Let the debate begin!

Cheers,

-koray

-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Ian McNicoll
Sent: Friday, 5 August 2011 11:03 p.m.
To: For openEHR technical discussions
Subject: Re: Multiple archetypes in a single concept as a way to create an 
archetype collaborative

Diego,

Very many thanks. I must have a nose around. You are right that they
are a number of archetype developed by 'the usual suspects' including
myself that are not yet on CKM. I have quite a number developed for a
paediatrics project which need to go up there. The problem, as ever,
is time. We do not want to put these archetypes , developed for a
particular project, up on to  CKM until we have at least established
that they are appropriate for sharing to a wider audience.

We will get there honest.

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 5 August 2011 11:41, Diego Bosc?  wrote:
> The archetypes you are talking about are available on this URL
> http://kenai.com/projects/openehr-app/sources/subversion/show/SANDBOX/openEHRApp_old/Archetypes?rev=726
>
> Tuberculosis ones need to be translated to English
>
> By the way, I found there some archetypes from usual CKM archetype
> authors that are not on the CKM (and quite good archetypes if you ask
> me...)
>
> 2011/8/5 Shinji KOBAYASHI :
>> Otherwise, I think these archetype developed for tuberculosis need
>> more discussion.
>>
>> 2011/8/5 Shinji KOBAYASHI :
>>> HI Joaquin,
>>>
>>> I remember that Cambodia group developed TB archetype at Kano labo in
>>> Waseda university.
>>> We can share information at our openehr.jp site.
>>> http://openehr.jp/news/9
>>>
>>> 2011/8/5 Blaya, Joaquin Andres :
 Thank you for all of the responses.  I have forwarded them to the OpenMRS 
 developer team.  A couple of other questions arose that I was hoping to 
 get cleared up.

 1. Are there tools or a portal for archetypes where different users can 
 share their archetypes?
 2. Have archetypes for Tuberbulosis, HIV and Malaria been created that can 
 be used in OpenMRS?

 Thanks again,

 Joaquin

 ___
 Chief Technology Officer, eHealth Systems Chile
 Research Fellow, Harvard Medical School/Partners In Health
 Moderator, GHDOnline.org

 ___
 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


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6352 (20110805) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6354 (20110805) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6354 (20110805) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

CCR model

[Koray Atalag]

Hi All, I need CCR model ASAP. has anyone worked on this. Possible to share?



Cheers,
-koray

FW: [openhealth] OpenGALEN and OpenEHR

[Koray Atalag]

Many of you probably got this but ...



From: openhealth at yahoogroups.com [mailto:openhea...@yahoogroups.com] On 
Behalf Of fred trotter
Sent: Sunday, 3 July 2011 5:40 p.m.
To: openhealth at yahoogroups.com
Subject: [openhealth] OpenGALEN and OpenEHR





Hi,
This list (openhealth) has been really silent for a long time. We
need a place where everyone who is interested in Open Source in healthcare
can continue to engage and talk. OSCON is having a healthcare track next
month, and the NWHIN has been huge for Open Source in healthcare. If you
want to go, I have a discount code 'os11fos' that will make it a little more
bearable.

Lots going on, but we, as a pan-project community are pretty silent about
things.

I am writing a book (with David Uhlman) about Health IT for
O'Reilly. I would love comments from this community.
http://ofps.oreilly.com/titles/9781449305024/

I need to get some updates on some projects related to ontologies and I was
hoping this group could help me.

This first is OpenGALEN http://www.opengalen.org
That project looks really interesting and have been doing releases for quite
some time, but I have some questions about the license and there is
apparently -no- way to engage with them. No email, only snail mail.
Despite regular releases, that makes me suspect that this is not a
legitimate open source project that has mechanisms in place for community
engagement. If you know anyone on that project give them a ring but at this
stage I am probably going to exclude covering their project, despite it
being pretty interesting subject matter and approach.

Also I would like to reach out to the OpenEHR folks. Lots of people I
respect have told me for quite some time that the whole archetype things is
really important. I have watched videos from the OpenEHR.org site and I
basically get what they are trying to do.

But from what I can tell, there is little benefit to OpenEHR over something
like SNOMED+UMLS+CDA.

I would love to be proven wrong here, but I need some concrete examples of
how the archetype approach lets you do things you cannot do with
SNOMED+UMLS+CDA alone. Unless someone can point me to something like this or
write something cohesive in an email response, I am going to exclude OpenEHR
from my ontology chapter as well.

These are the only Open Source ontology efforts that I am aware of. Can
anyone point me to other instances of healthcare ontologies (clinical not
genomic) that have the ontologie released in under an Open Source license?
Perhaps some project that is actually alive and relevant?

Do let me know...
And lets see some more chatter people

-FT

--
Fred Trotter
http://www.fredtrotter.com

[Non-text portions of this message have been removed]

__._,_.___

Reply to sender | Reply to 
group | Reply via web 
post
 | Start a New 
Topic

Messages in this 
topic
 (1)

Recent Activity:

Visit Your 
Group

MARKETPLACE

Stay on top of your group activity without leaving the page you're on - Get the 
Yahoo! Toolbar 
now.

 


Yahoo! 
Groups

Unable to express an unit of measurements in UCUM syntax

[Koray Atalag]

Hmm, haven't had a chance to read the full thread but does this mean I can also 
represent Gauge as a Quantity unit (which is not part of openEHR terminology) 
similarly? 

Cheers,

-koray


-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 27 May 2011 4:24 a.m.
To: openehr-technical at openehr.org
Subject: Re: Unable to express an unit of measurements in UCUM syntax

On 26/05/2011 16:48, Leonardo Moretti wrote:
> Hi all,
> I thought a lot on your proposal.
>
> If we want to use pseudo-units (non-UCUM terms), then we have to be able to
> distinguish when a term is in UCUM syntax. For example g/m2.7 is a valid
> UCUM string, but it is interpreted as (g/m^2) * 7 and not as g/(m^2.7),
> because in UCUM ?.? is the symbol for multiplication operator.
> So ?units? attribute should become a sort of code phrase, with the
> information on adopted syntax. Otherwise we can have an ambiguous syntax.

I am surprised that precedence does not force the reading of the full 
number following a '^', or a unit like 'm' when the '^' is inferred. I 
will have to look at my own UCUM parser to see what it does!

> As alternative, if we want to go on using only UCUM syntax, we could express
> this pseudo-unit (and not standard units) with the so-called annotation,
> wrapped in curly braces (see
> http://aurora.regenstrief.org/~ucum/ucum.html#section-Character-Set-and-Lexical-Rules,
> section 6). In this case, we can adopt {g/m2.7} safely, remaining compliant
> with the UCUM syntax.

I actually think that is a good idea. Have you looked for a mailing list 
or place in HL7 where you can make that proposal?

- thomas beale

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

FW: New Zealand's Interoperability Reference Architecture is out - open for public comment

[Koray Atalag]

Didn't seem to appear on technical list - resending. Sorry for cross-post



Cheers,

-koray



From: openehr-clinical-bounces at openehr.org 
[mailto:openehr-clinical-boun...@openehr.org] On Behalf Of Koray Atalag
Sent: Thursday, 19 May 2011 12:37 p.m.
To: For openEHR clinical discussions; For openEHR technical discussions
Subject: New Zealand's Interoperability Reference Architecture is out - open 
for public comment



Hi Folks,



This is a chance to openly view NZ's national (still draft though) reference 
architecture for interoperability. Underpinned by DCM - well practically 
archetypes (13606/openEHR), we suggest the use of numerous standards together 
in a pragmatic way. CDA, IHE and especially SOA is there.



So this is open for public comment until 3rd June and this is a chance where 
you can really make valuable contributions. Here's the link to the blog post 
for details (and download the pdf).



http://www.hive.org.nz/content/interoperability-reference-architecture-draft-version-comment-and-feedback-0



Happy reading!



Cheers,



-koray



__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6133 (20110518) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 6133 (20110518) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110519/8fb5055e/attachment.html>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: ATT1.txt
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110519/8fb5055e/attachment.txt>

New Zealand's Interoperability Reference Architecture is out - open for public comment

[Koray Atalag]

Hi Folks,



This is a chance to openly view NZ's national (still draft though) reference 
architecture for interoperability. Underpinned by DCM - well practically 
archetypes (13606/openEHR), we suggest the use of numerous standards together 
in a pragmatic way. CDA, IHE and especially SOA is there.



So this is open for public comment until 3rd June and this is a chance where 
you can really make valuable contributions. Here's the link to the blog post 
for details (and download the pdf).



http://www.hive.org.nz/content/interoperability-reference-architecture-draft-version-comment-and-feedback-0



Happy reading!



Cheers,



-koray

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

GUI stuff in AOM/ADL? (Was: future ADL-versions)

[Koray Atalag]

Hi Tom, others

I now see all points. I really like the idea of specialised templates used for 
GUI hints (as well as for other usual purposes) and that we have the usual 
shared templates without any of this. I am happy to put our contributions and 
encourage others to do so. The thing is many of the design decision we made 
were influenced by our lead developer, Dr. Yang, who didn't really know much 
about openEHR in the beginning. But he ws able to relate many existing software 
engineering practices and theory to this world. I thing we need to engage more 
people who are are really objective in this space.

Cheers,

-koray


From: openehr-technical-bounces at openehr.org [openehr-technical-bounces at 
openehr.org] On Behalf Of Thomas Beale [thomas.be...@oceaninformatics.com]
Sent: Saturday, 26 March 2011 2:05 a.m.
To: openehr-technical at openehr.org
Subject: Re: GUI stuff in AOM/ADL? (Was: future ADL-versions)

On 25/03/2011 03:05, Koray Atalag wrote:
Hi Eric, good points...As you may remember we had this discussion on this list 
not so long ago and I don?t remember any action taken after that. I guess we 
should take lead and come up with some proposal. Perhaps it?d be good to have a 
wiki space  - but I want to repeat myself: someone from core group must guide 
the group and provide early feedback whether we are on the right track or not.

To all interested in this area: in terms of innovation and ideas, the people in 
this discussion are the 'core group'.  Advice from myself and others 
historically working on the specifications is as I have already posted, i.e. 
IMO, stick to the separation of concerns with respect to artefacts. I 
personally would not include GUI-related hints in templates either, because 
there will eventually emerge some templates that are widely shared, e.g. 
national and international (e.g. European) discharge summary, referral, 
e-prescription etc - but whose GUI models are very unlikely to be shared. On 
that view of things, you don't want to have to revise such a published resource 
due to some particular GUI directives buried inside it. This doesn't mean that 
the ADL (abstract or XML form) formalism can't be used, but I still think a 
separation of the pieces will make dependency and release management a lot 
easier. Erik may be right: if the GUI hints can be expressed in a template, 
then by definition, it can be done in a specialised template, and that can 
clearly be local.

At the moment, we have to consider this area as 'industrial research', and I 
for one would encourage all experimentation to be published and flagged on this 
list, as a way of getting us all on the same page with respect to lessons being 
learned.

- thomas beale

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110329/2966f07b/attachment.html>

GUI stuff in AOM/ADL? (Was: future ADL-versions)

[Koray Atalag]

Hi Eric, good points...As you may remember we had this discussion on this list 
not so long ago and I don't remember any action taken after that. I guess we 
should take lead and come up with some proposal. Perhaps it'd be good to have a 
wiki space  - but I want to repeat myself: someone from core group must guide 
the group and provide early feedback whether we are on the right track or not.

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Erik Sundvall
Sent: Thursday, 24 March 2011 9:06 p.m.
To: For openEHR technical discussions
Subject: GUI stuff in AOM/ADL? (Was: future ADL-versions)

Hi!

Yesterday I asked if anybody had any motivated objections to using the openEHR 
template formalism as a layer to catch some GUI-hints/rules. I bring it up 
again to get some response :-)

The point to have separate concerns in separate artifacts is often good. 
Regarding GUI-hints it seems reasonable to not have them at the clinical 
archetype level, and in some cases not at a first clinically focused template 
level either. But, as we have discussed earlier, through specialisation and/or 
inclusion it's possible to have several layers of openEHR templates.

This means that ADL or some other serialisation format of the archetype object 
model (that now will include templates) can be used for GUI-related annotations 
and GUI-related logic in some form. Does anybody have concerns or worries 
regarding this?

You could still have separate artifacts by splitting reusable clinical modeling 
and use case specific GUI modeling in separate layers of templates.

A nice thing with reusing the template formalism for catching GUI stuff is that 
shared tools and understanding is already in place as opposed to inventing some 
new purely GUI-related formalism. Also in some cases it's likely that the same 
groups that are designing archetypes and clinically focused templates will have 
knowledge of some use cases in which they know what they'd want to happen on 
the GUI side. Then it would be nice to be able to reuse people, tools, template 
governance repositories etc.

Best regards,
Erik Sundvall
erik.sundvall at liu.se 
http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

P.s. (off topic)
I'm not sure it's always optimal to split everything into separate artifacts, 
especially when it comes boundary problems like terminology bindings. You could 
argue that the binding should be done in a separate artifact that is neither 
part of archetypes nor part of terminologies, but I'm not sure that would 
always make things better. Having the bindings in the archetype forces the 
archetype authors to revise the bindings at the same time as they revise an 
archetype and that might be good.

On the other hand you could argue that a SNOMED CT refset might be exactly such 
a third artifact that can be used for managing bindings. But if you would have 
three different groups maintaining archetypes, refsets and terminology systems 
then you'd better keep them very well aware of each other's actions...

On Wed, Mar 23, 2011 at 21:09, pablo pazos mailto:pazospablo at hotmail.com>> wrote:
I agree with Thomas, in order to have a clean design we need to separate the 
concerns of our artifacts. If we have a solid base to our complete clinical 
data structures like Archetypes, we can define other "upper layer" artifacts to 
model rules, conditions, gui directives, etc.

I like this approach because we can solve one problem at a time, instead of 
having a messy one-fits-all solution.
-- next part --
An HTML attachment was scrubbed...
URL: 

Sample OpenEHR records

[Koray Atalag]

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-boun...@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

Representing binary values with DV_BOOLEAN

[Koray Atalag]

I kind of think that is the case and fully agree with your profat least 
3-states. In fact I cannot understand why this hasn't a big issue in other 
domains and have been ubiquitously used for many years everywhere.

Looking at the data structures and types RM since an ELEMENT with DV_BOOLEAN 
value will also have null_flavours attribute this 3-state requirement is met 
readily. I think the problem is using a 2-state checkbox or similar widget and 
binding any of the states to null. The widget also should have at least 
3-states.

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of pablo pazos
Sent: Wednesday, 9 February 2011 5:19 p.m.
To: openehr technical
Subject: RE: Representing binary values with DV_BOOLEAN

Once, a professor told me: in healthcare there is no boolean data, you need at 
least three values, because there must be a registry of the data that is not 
recorded (like a null value), the item is there (the ocurrence of the node is 
1), but the value is null. The data that is not recorded could have 
medico/legal value/semantics.

Of course, you may need something to know why the data was not recorded, like a 
"null flavour", something like: I did't ask, the patient don't want to tell me, 
the patient don't have the information, the patient can't ask, etc.

Personally I don't see much use of the DvBoolean alone.

--
Kind regards,
A/C Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos



From: sam.he...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: RE: Representing binary values with DV_BOOLEAN
Date: Wed, 9 Feb 2011 11:54:49 +0930
Hi

The issue needs to be discussed first in the modelling of the archetype. If a 
Boolean is accepted at this level then that is what it is (for the moment) and 
how that is displayed on the screen then becomes an issue. I agree that 
positive/negative != True/False. 'Test Positive' could have a true/false as in 
Test result abnormal in HL7 lab tests.

Fabiane's idea that a Boolean defaults to false seems to be an implementation 
issue - it is possible to have a tri-state Y/N/Null widget to cope with the 
null.

This is a worthwhile discussion.

Cheers, Sam




From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Koray Atalag
Sent: Wednesday, 2 February 2011 12:40 PM
To: For openEHR technical discussions
Subject: Representing binary values with DV_BOOLEAN

Hi All, I'd like to get feedback on this issue before we move on with 
implementing.

In short whether we should use DV_BOOLEAN to represent the result of a Lab test 
as Positive/Negative. This particular test can have only two values (well plus 
the null case of course). I suspect this wasn't the purpose of this data type 
in the first place and was for really no-brainer yes/no items as you would 
expect in any computer program. But, as ever, clinical medicine is wicked and 
makes me think out of the 'usual' good practice and explore whether this might 
be an option...Perhaps this discussion will provide guidance for others in the 
community as well.

Secondly (assuming that we can use DV_BOOLEAN for such cases) in GUI not all 
occurrences of Boolean will have labels as Yes/No...It can also be True/False, 
Present/Absent, Positive/Negative etc. Moreover in difference language 
translations they will surely be different. But in ADL no at code is given for 
this data type; Yes and No is written implicitly within the definition section. 
This means that we cannot set the Text in ontology section and then have 
language translations. Has anyone come across such a requirement? If so what's 
your solution.

Note that I currently model all such data items with DV_CODED_TEXT and had no 
problems. But when I wanted to render radio buttons for Yes/No type items 
instead of default combobox widget I either need a GUI directive (which we try 
to avoid if possible) or set the data type to DV_BOOLEAN so that the default 
widget would be radio button and we can use accordingly.


Cheers,

-koray


___ 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: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110209/68a41cb7/attachment.html>

Representing binary values with DV_BOOLEAN

[Koray Atalag]

Hi Diego, thanks for your points...

I agree that changing data item to 'Test X result Positive: True|False' is the 
right way to use Boolean data type...But while this is an elegant technical 
approach it has problems in two ways (in my opinion):

1) From modelling point of view the non-techy domain experts may find this type 
of thinking and hence naming of data items difficult. The straightforward way 
of modelling would be to insert a node with text corresponding to the screen 
label (i.e. Test X) and then put values positive|negative. It would be implicit 
to clinicians that these values actually are "Result" of the Text X.

2) This representation also when it comes to automatic GUI generation will be 
quite problematic as the generator needs to know how to represent the correct 
semantics on the form. In this case I would assume we'd need a GUI directive 
perhaps stating how to render this correctly on screen. So in our example it 
has to:
a) Extract data item name from Text of archetype node (i.e. Test X). 
Actually it is not possible to deduce this if the naming is done with some 
convention (i.e. Test XRest of the name; like 'Test X<%> result 
positive'
b) Get labels for values from GUI directive (i.e. DirectiveA 
(labels:positive|negative). Or use the Description property of at code to 
insert these (i.e. using a custom syntax)
c) Put a label with text from (a) on form
d) Put widgets for values: 
- in our case two radio buttons with labels positive and 
negative or simply (+) and (-). 
- Alternatively a combobox with these two entries.
- Or two radio buttons with captions positive and negative
- Or kind of precoordination; merge label and value and display 
two radio buttons with labels Urease(+) and Urease(-).

Perhaps in (d) a better way of displaying this node (for reasons Eric has 
mentioned) might be to just put a single checkbox next to the label (i.e. Test 
X) and bind checked value to positive etc. In our case we are working on the 
Rapid Urease Test which is either positive and negative. I'd like to see on our 
GUI the label and a checkbox next to it. Simple...

We are trying to come up with GUI directives which could handle all such 
alternative representations...Quite challenging but hopefully getting somewhere.

Any thoughts?

Cheers,

-koray


-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Diego Bosc?
Sent: Wednesday, 2 February 2011 4:28 p.m.
To: For openEHR technical discussions
Subject: Re: Representing binary values with DV_BOOLEAN

Is much different to change the field from 'test
result:positive/negative' to 'test result positive:true/false'?
If the semantics if not the same then the 'positive/negative' has more
meaning that a simple boolean and I think they should be coded

2011/2/2 Koray Atalag :
> Hi All, I'd like to get feedback on this issue before we move on with
> implementing.
>
>
>
> In short whether we should use DV_BOOLEAN to represent the result of a Lab
> test as Positive/Negative. This particular test can have only two values
> (well plus the null case of course). I suspect this wasn't the purpose of
> this data type in the first place and was for really no-brainer yes/no items
> as you would expect in any computer program. But, as ever, clinical medicine
> is wicked and makes me think out of the 'usual' good practice and explore
> whether this might be an option.Perhaps this discussion will provide
> guidance for others in the community as well.
>
>
>
> Secondly (assuming that we can use DV_BOOLEAN for such cases) in GUI not all
> occurrences of Boolean will have labels as Yes/No.It can also be True/False,
> Present/Absent, Positive/Negative etc. Moreover in difference language
> translations they will surely be different. But in ADL no at code is given
> for this data type; Yes and No is written implicitly within the definition
> section. This means that we cannot set the Text in ontology section and then
> have language translations. Has anyone come across such a requirement? If so
> what's your solution.
>
>
>
> Note that I currently model all such data items with DV_CODED_TEXT and had
> no problems. But when I wanted to render radio buttons for Yes/No type items
> instead of default combobox widget I either need a GUI directive (which we
> try to avoid if possible) or set the data type to DV_BOOLEAN so that the
> default widget would be radio button and we can use accordingly.
>
>
>
>
>
> Cheers,
>
>
>
> -koray
>
>
>
> ___
> 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

Representing binary values with DV_BOOLEAN

[Koray Atalag]

Hi All, I'd like to get feedback on this issue before we move on with 
implementing.

In short whether we should use DV_BOOLEAN to represent the result of a Lab test 
as Positive/Negative. This particular test can have only two values (well plus 
the null case of course). I suspect this wasn't the purpose of this data type 
in the first place and was for really no-brainer yes/no items as you would 
expect in any computer program. But, as ever, clinical medicine is wicked and 
makes me think out of the 'usual' good practice and explore whether this might 
be an option...Perhaps this discussion will provide guidance for others in the 
community as well.

Secondly (assuming that we can use DV_BOOLEAN for such cases) in GUI not all 
occurrences of Boolean will have labels as Yes/No...It can also be True/False, 
Present/Absent, Positive/Negative etc. Moreover in difference language 
translations they will surely be different. But in ADL no at code is given for 
this data type; Yes and No is written implicitly within the definition section. 
This means that we cannot set the Text in ontology section and then have 
language translations. Has anyone come across such a requirement? If so what's 
your solution.

Note that I currently model all such data items with DV_CODED_TEXT and had no 
problems. But when I wanted to render radio buttons for Yes/No type items 
instead of default combobox widget I either need a GUI directive (which we try 
to avoid if possible) or set the data type to DV_BOOLEAN so that the default 
widget would be radio button and we can use accordingly.


Cheers,

-koray

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

Archetype & Template ANNOTATIONS - requirements?

[Koray Atalag]

Hi Tom, I wasn't aware of that - thanks.

My initial thinking was to introduce GUI directives at the template level, 
persisting with it and passing  onto OPT. I was reluctant to introduce 
"yet-another-layer" due to mainly maintainability concerns but it has been 
suggested that tooling should be able to handle that and hide complexity from 
users. That makes sense now (still with caution though ;).

Until this is defined may I suggest reserving a keyword (i.e. "GUI directive") 
for use in annotations section. Or perhaps this can just be a design-pattern as 
you originally suggested which we all stick to so that our existing 
implementations will have some level of interoperability?

I'd be very keen to contribute to the definition of a new GUI artefact; perhaps 
it'd be great if you could provide a basis for (i.e. such as an initial set of 
requirements and design principles inline with the current specs and where 
openEHR wants to go) and facilitate the discussions. Referring back to Eric's 
and Thilo's messages perhaps we can work as a working group or a SIG and come 
up with useful proposals.

Another point was whether there were any directives to do with the structure 
and semantics (hence domain knowledge) within the list we came up with. The 
"CoreConcept" directive which basically depicts whether a CLUSTER and its 
downstream items can be recorded as absent, indeterminate etc. Ian also pointed 
out a more comprehensive set of requirements around the same issue referring 
the need to the need to represent detailed clinical findings without the need 
to insert unnecessary CLUSTERS for single ELEMENTS which may hold further 
ELEMENTS in future when there is a need to extend. I am not aware of the result 
of this discussion (if any) either.

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: Thursday, 30 December 2010 1:10 p.m.
To: openehr-technical at openehr.org
Subject: Re: Archetype & Template ANNOTATIONS - requirements?

On 29/12/2010 23:53, Koray Atalag wrote:
Hi Tom, a very comprehensive set of questions to determine the requirements...

I will provide my point by point feedback shortly but I have one 
objection/suggestion re using annotations for GUI matters.
As name implies annotations seem to me something for the humans; providing 
context and additional information about a particular data point. Exploiting 
this section for GUI generation which will be consumed by GUI tools/generators 
do not seem all too appropriate to me. What I have in mind is a separate 
section for GUI Directives or at least introduce a reserved keyword for this 
purpose within annotations section. I think that'll ensure more consistent and 
safe implementations by different groups. Both support your points about tag 
standardisation...

Hi Koray,

the annotations section is not connected with GUI directives. I think we are 
all agreed they will be in a completely separate artefact.

- thomas
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101230/b2817693/attachment.html>

Archetype & Template ANNOTATIONS - requirements?

[Koray Atalag]

Hi Tom, a very comprehensive set of questions to determine the requirements...

I will provide my point by point feedback shortly but I have one 
objection/suggestion re using annotations for GUI matters.
As name implies annotations seem to me something for the humans; providing 
context and additional information about a particular data point. Exploiting 
this section for GUI generation which will be consumed by GUI tools/generators 
do not seem all too appropriate to me. What I have in mind is a separate 
section for GUI Directives or at least introduce a reserved keyword for this 
purpose within annotations section. I think that'll ensure more consistent and 
safe implementations by different groups. Both support your points about tag 
standardisation...

Cheers & happy new year,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 24 December 2010 12:25 a.m.
To: Openehr-Technical; For openEHR clinical discussions
Subject: Archetype & Template ANNOTATIONS - requirements?


All,

the next beta of the archetype workbench, which is progressively implementing 
all of ADL 1.5 will include 'annotations', which is a feature enabling a set of 
comments to be created on a per-node level in an archetype. The raw ADL 
appearance of this is typified by the following two test archetypes (go to the 
bottom): 
http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/ADL_1.5_test/validity/annotations/

For a given node (i.e. path) and a given language in an archetype or template, 
the annotations are a set of name-value pairs (technically a Hash of Strings, 
with String keys). This means you might have the following on some node in an 
archetype (keys in italics, values to the right):

 *   clinical justification: "see xyz examination protocol, at 
http://medline.org/some/ref.html";
 *   data type: "free text with optional preferred coding"
On a template, we would expect the annotations  to be more local, e.g.:

 *   NHS data dictionary: "See doc x, ref y"
 *   Terminology: "constrained according to NHS ED 4h protocol"
Of course we don't know exactly how things will turn out, so we need to see 
some experimentation in the real world.

REQUIREMENTS QUESTIONS - please provide feedback:

 *   BASIC REPRESENTATION: all annotations are (unicode) String values with 
(unicode) String keys,
*   this allows any string, including in script languages like Farsi, 
Hindi, Chinese etc
*   Q1: is such a structure powerful enough? It might be argued that the 
keys should be internal codes, i.e. at-codes, or external coded concepts, e.g. 
SNOMED codes.
 *   PERSISTENCE: where do annotations get recorded?
*   if annotations are regarded as an intrinsic part of an archetype, they 
are recorded in the archetype: this is what we have currently implemented
*   if annotations are regarded as intrinsically part of the local use 
environment, then they would be persisted as some adjunct artefact that 
references an archetype, or else in specialised archetypes/templates, even if 
no other constraints are added to the archetype proper; we have currently 
assumed the latter.
*   Q2: if both are assumed, then some rules for a) translations and b) 
merging are required; SEE BELOW
 *   LANGUAGE annotations groups (i.e. set of key, value) on a per-language 
basis, i.e. 'en' annotations separated from 'es' from 'cz' etc in the usual way
*   Q3:  this means that for a given archetype, there is a choice with 
respect to translations:
   *   force translation of all annotations to all languages available for 
this archetype: this is probably reasonable for international archetypes on 
CKM, since any such annotations must presumably be relevant no matter what 
language
   *   for any given archetype, within a specific use context, allow just 
the annotations in the local language to exist? This appears to be reasonable, 
since just because a CKM archetype had a Swedish translation doesn't mean your 
local users in Beijing should translate their annotations to Swedish...
   *   If the answer to Q2 is that a mixture is allowed, then we should 
allow both of above possibilities for translation, and we assume that any local 
translations are within local archetypes / templates. I.e. you can't add 
annotations outside of an archetype or template.
 *   TAG VALUES: should keys be standardised in some way? Currently, we 
implemented just Strings. The answer depends on our notion of how interoperable 
annotations should be.
*   Q4: Requirements possibilities:
   *   no standardisation (what has currently been assumed)
   *   international standardisation only - i.e. only CKM archetypes would 
have standardised tags; this can be supported with the 'no standardisation' 
option as well, since centralised/standardised tooling could ensure standard 
tag sets.
   *   standardisation at a national level, perhaps in concert (

GUI-directives/hints again (Was: Developing usable GUIs)

[Koray Atalag]

Hi, I don?t mean to be too pushy on this but I think we are not really on the 
same grounds at the moment. I?ll try to summarise my points:


-  Re universality I agree with you as you describe but I have 
indicated that this pattern is unique to certain type of observations; so 
perhaps I shouldn?t have used the term universal but ?common? in many types of 
clinical findings as a result of some examination. The exclusions you give by 
examples are very appropriate.

-  It is perfectly possible, and indeed during the diagnosis of acute 
appendicitis essential, to denote absence of lump or ?lack of rebound reflex? 
is almost common expression and pathognomonic to the disease. So I don?t agree 
with you and my gut feeling is that all findings during physical examination 
may well be reported as absent.

-  Yes I?d be also very interested to identify and classify if possible 
which ones ? but again my gut feeling is that this may not be possible and that 
relies on the clinical context and semantics. Therefore instead of identifying 
these at the outset I think giving the modellers a method to tag these will be 
the pragmatic solution and enable consistency among modellers and 
implementations.

-  Re design patterns and tooling support ? I think this should be in 
place in any case. But as Ian has pointed out there is more to the problem than 
convenience for modellers. The problem is consistency among modellers and mode 
critically when these models need to evolve (which is almost guaranteed) then 
how to avoid changes in paths?i.e. many ELEMENTs will need to be converted to 
CLUSTERS. Conversely if you anticipate this and design accordingly you might 
end up having zillion of unnecessary CLUSTERS with single ELEMENTs?

Hey Ian! I liked your proposal?Never been to Bahamas

Cheers,

-koray

From: openehr-clinical-bounces at openehr.org 
[mailto:openehr-clinical-boun...@openehr.org] On Behalf Of Sam Heard
Sent: Thursday, 16 December 2010 9:22 a.m.
To: For openEHR clinical discussions
Cc: openehr-clinical at openehr.org
Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs)

Hi All
I sense Thomas is right. If you look at the exam archetypes there is a pattern 
of unlimited normal statements. This allows anything to be said but for it to 
be classified as normal even if it is text. There is work to do on examination 
as it is fractal and varies on a case by case basis.
Happy to talk about this at the implementation meeting.

Cheers Sam

Sent from my extphoney

On 16/12/2010, at 6:24 AM, Thomas Beale mailto:thomas.beale at oceaninformatics.com>> wrote:
On 15/12/2010 19:20, Koray Atalag wrote:
Hi Tom, I agree that the this is best way how to ?represent? data technically. 
But what I suggest is, since this is a universal and repeating pattern for all 
clinical findings (and maybe more) can?t we have an extension in ADL such that 
we ?tag? a certain sub-tree and then this node is inserted into ADL source 
automatically. And the way we write queries and process that would be uniform 
and convenient.

Cheers,

I am pretty sure it is not universal. Consider any standard lab, e.g. full 
blood count. Each analyte that is reported is there; if a proper value can't be 
reported, e.g. haemolysed attached specimen, you get just a report with that in 
it; otherwise you get numbers (including things like 'trace' where appropriate) 
and normal ranges. This is a different pattern. A reflex test is going to 
report a reaction to a stimulus, for each of a number of locations on the body. 
This will be a different pattern again ('no reaction' is just a value among 
other values of reaction strength).

Your pattern might be a typical pattern for various kinds of physical 
examination, where the examination proceeds on the basis of looking for a very 
specific set of possible anomalies, in the way that colonoscopy does. But even 
then, physical exam of e.g. abdomen is not going to report 'lump: absent' if no 
lump was encountered in a routine check.

I agree it is likely to be a common pattern in some kinds of examination, and 
it would be interesting to know which ones, and how these could be categorised. 
I would suggest that what you are really after is a library of 'archetype 
design patterns' that are available to tools, enabling you to quickly build the 
definitions for a whole lot of nodes according to a chosen pattern.

My suggestion is to try to identify and document such patterns - I started a 
page on this about 1year ago at 
http://www.openehr.org/wiki/display/healthmod/Archetype+Design+Patterns+-+Initial+Thoughts

- thomas


___
openEHR-clinical mailing list
openEHR-clinical at openehr.org<mailto:openEHR-clinical at openehr.org>
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
-- next part --
An HTML attachment was scrubbed..

New requirements from endoscopy (was Re: GUI-directives/hints again (Was: Developing usable GUIs))

[Koray Atalag]

Hi Tom, I'll try to make a few things clear. I'll chop off parts of my original 
message for better readability.


.
However clinical findings, as in our case, essentially require to be depicted 
as unknown or absent explicitly. We have initially thought we could solve the 
issue by using flavours of null which is defined by openEHR RM for each ELEMENT 
data item (caution here it is only for ELEMENT) but the problem is that these 
findings are represented using CLUSTERs not ELEMENTs in our MST Archetypes. 
This is because we use ELEMENTs under each CLUSTER to depict properties or 
attributes of those findings such as size, number extent etc. And we cannot 
represent Absent with flavours of null either.

Koray, I don't get this bit: you are saying you want the effect of flavours of 
null for whole sub-trees of information?


Yes I suggest that we have some means to indicate the presence state of a whole 
sub-tree with further qualifiers as to  why information was not available. I am 
talking about present (well this is straightforward), absent (there has been an 
effort to find a certain lesion but it was not there) and unknown/indeterminate 
(which I think flavours of null can be used to further qualify). I think the 
absent option can simply be handled by negation of present (as Graeme 
mentions); but not sure how to do that in openEHR.


.

We think this might best be denoted in the RM; either at CLUSTER or ITEM 
classes. Something like null flavours but not quite the same. Or perhaps a 
dedicated new class?? That's up to the discussions.

well moving null flavours to ITEM (meaning CLUSTER and ELEMENT both get it) 
would not be that hard to do - it has no negative impact on anything. But we 
have not done any general semantic analysis on this idea...

Happy to provide you with more information and help with that if 
necessary.

.

To depict standalone findings during archetype design setting the cardinality 
of CLUSTER to 0..* or 0..n can be used. But currently we cannot set cardinality 
to 0 for CLUSTER: this is not allowed according to AOM (although in openEhrV1 
it's possible to have CLUSTER's with 0 ITEM's as long as it isn't validated by 
the RmValidator, this isn't considered a desirable usage).


but you can't record any data in a CLUSTER with no children. If the CLUSTER is 
named (i.e. has at-code) for 'haemorrhoids' the implication is that something 
is going to be said about this. The function of this name/code here is as a 
name, not as a value. Some ways of doing this would be:

ELEMENT [haemorrhoids]; value = present

This won't work for us because almost all findings are qualified by attributes 
and associated by anatomical sites. So it has to be under a cluster as a 
sub-tree

or

CLUSTER [haemorrhoids];
CLUSTER -- more complex description of haemorrhoids
ELEMENT
ELEMENT
etc

Well close but not exactly. Our modelling approach is:

CLUSTER occurrences {0..*} [Tumour] (note that this whole sub-tree can repeat 
as a whole for defining same finding with a different set of qualifiers)
ELEMENT {0..1} [Type] --- values
ELEMENT {0..1} [Stage]  --- values
ELEMENT {0..1} [Extent]  --- values
ELEMENT {0..*} [Sites] --- values (note that this can be multiple with 
occurrences set to 0..*)

So when we create the 'value' instance which  is a shadow of the opt we have 
all parts of the model in place - i.e. all ELEMENTS have null values and 
obviously CLUSTERS holding them are all instantiated. When use enters data from 
GUI the widgets are bound to the parts of the instance and values are updated. 
If a multiple entry has been made then new instances of some subtrees are added 
to the 'value' instance. However when persisting this 'value' instance we prune 
all null sub-trees and then serialise and save.

So the point is we never have empty CLUSTERS which we want to store data; but 
what happens is initially lots of CLUSTERS holding sub-trees are instantiated 
with all its ELEMENTs with null/default/assumed values. As I explained in order 
to represent the presence of this sub-tree we insert a special ELEMENT which 
depicts this presence information to each and every sub-tree. And we then have 
to hardcode this in our application which makes me uncomfortable. I think it is 
not good modelling practice to do this manually. Perhaps best way would be not 
to touch the current data structures but introduce a custom syntax in ADL which 
will make things easier and more consistent among different implementations.

or

CLUSTER [features present];
ELEMENT [observed feature]; value = haemorrhoids
ELEMENT [observed feature]; value = something else
etc

Same as first one - won't work

The real issue is a bit more tricky and has to do with core semantics: it 
doesn't make sense to depict a finding as absent or unknown when qualified by 
certain attributes.



ok, so absence / negation is a common requirement in e

GUI-directives/hints again (Was: Developing usable GUIs)

[Koray Atalag]

Thanks a lot Helma - lots of reading material for Xmas!

Cheers,

-koray

-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of hepabolu
Sent: Wednesday, 15 December 2010 8:58 a.m.
To: For openEHR technical discussions
Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs)

Hi everyone,

for those interested, my full thesis is available here:
http://www.sourcefusion.nl/thesis/Dissertation-HvdL.pdf

A link on the openEHR website to this PDF is appreciated.

Sorry for not participating in the discussion, but my current job has me 
swamped with work and deadlines.

With regards,

Helma van der Linden


Thilo Schuler said the following on 13/12/2010 07:20:
> Hi everybody,
>
> I got permission to publish the MedInfo paper and its successor
> mentioned below.
>
> You can find it here (last row of table):
> http://www.openehr.org/wiki/display/resources/MedInfo+2007+-+Brisbane+Australia
>
> Cheers,
> Thilo
>
>
> After that Helma, her supervisor, Rong and I published a very
> future-oriented paper
> 
> 
> about sharing not only archetypes but also GUI artefacts. Helma
> later extended this idea in a chapter of her thesis and
> (re)published  it. I
> will ask her whether we can put the paper and her thesis on the wiki
> (maybe she reads this anyway... Hello Helma?).
> This is definitely far away from end-to-end applications and it is
> unclear whether it will ever be realisable but it still has some
> very interesting thoughts for our discussion.
> An extended version of Lisa's EhrView mechanism
>  with
> a repository of XSLT-fragments is - IMO - something that could
> definitely be realised in the midterm to provide an enhanced
> read-only view of arbitrary openEHR information.
>
>
>
>
> ___
> 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

GUI-directives/hints again (Was: Developing usable GUIs)

[Koray Atalag]

s is a perfectly valid (and quite frequently used) expression in 
endoscopy reporting: "Villous polyps were absent at ascending colon" (here 
villous is an attribute for type of polyp).

Another invalid expression: "3 cm long stenosis was been absent..."

So it looks like some qualifiers may change the existence of core concepts - so 
perhaps we need some means to tag them during modelling. It looks like these 
are 'physical' properties and not 'man-made' concepts.

Hope this helps to elaborate things...

Cheers,

-koray & hong yul

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 10 December 2010 1:15 p.m.
To: openehr-technical at openehr.org
Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs)

On 09/12/2010 21:37, Koray Atalag wrote:
Hi All,

I've read similar work before starting with our design and found Thilo's prior 
work very relevant and well researched. This MIEUR 2006 paper describes a new 
layer of GUI model using Mozilla XUL - an XML based open web layout standard. 
AT the time of writing templates were not out there yet and from his discussion 
I reckon much of the GUI definition could be handled by templates. I now agree 
that pure GUI stuff must be represented elsewhere - but at the moment we find 
template annotations quite useful and sufficient. Be aware that our app is a 
Winforms one - not Web based. So the kind of GUI rules might differ from others 
which are almost all Web based.

And one note to Thomas: we actually use templates for defining a minimum data 
set (yes not a maximal) for the purpose of reporting...

that is more or less the intention of templates. Archetypes define 'maximal' 
sets of data points; templates define what you actually want to use in some 
circumstance.


So w have both data entry/validation and reporting layout issues. Not messaging 
though but we are planning to transform the openEHR instance of endoscopy 
report into CDA and exchange with HL7 V2.x in near future.

It would be interesting to see if you have some 'semantic' rules you think are 
needed in templates, as opposed to layout rules - can you summarise?

- thomas




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/25ab11ee/attachment.html>

GUI-directives/hints again (Was: Developing usable GUIs)

[Koray Atalag]

Thanks Thile, didn't have this paper before - will read now with much pleasure 
:)

Hong Yul and I had a long discussion yesterday and will prepare a joint 
response today or tomorrow (well NZ time of course!). Especially Tom has asked 
whether we have any issues which might need to go into Templates or Archetypes 
that has to do with the semantics and structure rather than GUI only. We think 
that we do but need first to define and be able to articulate in plain words.

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thilo Schuler
Sent: Monday, 13 December 2010 7:20 p.m.
To: For openEHR technical discussions
Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs)

Hi everybody,

I got permission to publish the MedInfo paper and its successor mentioned below.

You can find it here (last row of table): 
http://www.openehr.org/wiki/display/resources/MedInfo+2007+-+Brisbane+Australia

Cheers,
Thilo

After that Helma, her supervisor, Rong and I published a very future-oriented 
paper
 about sharing not only archetypes but also GUI artefacts. Helma later extended 
this idea in a chapter of her thesis and 
(re)published it. I will ask her 
whether we can put the paper and her thesis on the wiki (maybe she reads this 
anyway... Hello Helma?).
This is definitely far away from end-to-end applications and it is unclear 
whether it will ever be realisable but it still has some very interesting 
thoughts for our discussion.
An extended version of Lisa's EhrView 
mechanism 
with a repository of XSLT-fragments is - IMO - something that could definitely 
be realised in the midterm to provide an enhanced read-only view of arbitrary 
openEHR information.

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

GUI-directives/hints again (Was: Developing usable GUIs)

[Koray Atalag]

Sorry forgot Thilo's paper info:

1.

Schuler T, Garde S, Heard S, Beale T. Towards automatically generating 
graphical user interfaces from openEHR archetypes. Stud Health Technol Inform 
2006;124:221-6.





Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of pablo pazos
Sent: Thursday, 9 December 2010 7:39 a.m.
To: openehr technical
Subject: RE: GUI-directives/hints again (Was: Developing usable GUIs)

Hi Ian,

If I understand what Thomas said "I would suggest that the GUI templates just 
reference paths found in the openEHR template", the paths in a GUI Template 
will come "only" from openEHR templates (the structural ones), not from 
archetypes (this is apart from that they are technically the same thing).

I think in ADL 1.4 the template specification is not complete, I would say that 
in 1.4 Templates are not so clear Archetype specializations.
In ADL 1.5 is more clear the relationship of Templates and Archetypes.

What I meant in the previous mail was: for us who have developed applications 
over ADL 1.4, our GUI Templates will use paths "directly" from Archetypes, 
instead of paths from openEHR structural Templates.

--
Kind regards,
A/C Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos



> From: Ian.McNicoll at oceaninformatics.com
> Date: Wed, 8 Dec 2010 17:30:38 +
> Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs)
> To: openehr-technical at openehr.org
>
> Hi Pablo,
>
> In both ADL1.4 and 1.5 every path is still an archetype-based path.
> The proposed schema for an operational template is very similar to the
> XML schema of an individual archetype but obviously includes multiple
> aggregated archetypes and omits any nodes which are constrained out.
>
> Templates are technically identical to specialised archetypes. The
> difference is that specialised archetypes support templating features
> such as constraining out unwanted elements and aggregating archetypes.
>
> The only difference between an archetype and a template is that new
> content i.e. new nodes or terms cannot be added to a template.
>
> Ian
>
> Dr Ian McNicoll
> office / fax  +44(0)1536 414994
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
>
>
> Clinical analyst, Ocean Informatics
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care SG Group www.phcsg.org
-- next part --
An HTML attachment was scrubbed...
URL: 

GUI-directives/hints again (Was: Developing usable GUIs)

[Koray Atalag]

Hi All,

I've read similar work before starting with our design and found Thilo's prior 
work very relevant and well researched. This MIEUR 2006 paper describes a new 
layer of GUI model using Mozilla XUL - an XML based open web layout standard. 
AT the time of writing templates were not out there yet and from his discussion 
I reckon much of the GUI definition could be handled by templates. I now agree 
that pure GUI stuff must be represented elsewhere - but at the moment we find 
template annotations quite useful and sufficient. Be aware that our app is a 
Winforms one - not Web based. So the kind of GUI rules might differ from others 
which are almost all Web based.

And one note to Thomas: we actually use templates for defining a minimum data 
set (yes not a maximal) for the purpose of reporting...So w have both data 
entry/validation and reporting layout issues. Not messaging though but we are 
planning to transform the openEHR instance of endoscopy report into CDA and 
exchange with HL7 V2.x in near future.

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of pablo pazos
Sent: Thursday, 9 December 2010 7:39 a.m.
To: openehr technical
Subject: RE: GUI-directives/hints again (Was: Developing usable GUIs)

Hi Ian,

If I understand what Thomas said "I would suggest that the GUI templates just 
reference paths found in the openEHR template", the paths in a GUI Template 
will come "only" from openEHR templates (the structural ones), not from 
archetypes (this is apart from that they are technically the same thing).

I think in ADL 1.4 the template specification is not complete, I would say that 
in 1.4 Templates are not so clear Archetype specializations.
In ADL 1.5 is more clear the relationship of Templates and Archetypes.

What I meant in the previous mail was: for us who have developed applications 
over ADL 1.4, our GUI Templates will use paths "directly" from Archetypes, 
instead of paths from openEHR structural Templates.

--
Kind regards,
A/C Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos



> From: Ian.McNicoll at oceaninformatics.com
> Date: Wed, 8 Dec 2010 17:30:38 +
> Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs)
> To: openehr-technical at openehr.org
>
> Hi Pablo,
>
> In both ADL1.4 and 1.5 every path is still an archetype-based path.
> The proposed schema for an operational template is very similar to the
> XML schema of an individual archetype but obviously includes multiple
> aggregated archetypes and omits any nodes which are constrained out.
>
> Templates are technically identical to specialised archetypes. The
> difference is that specialised archetypes support templating features
> such as constraining out unwanted elements and aggregating archetypes.
>
> The only difference between an archetype and a template is that new
> content i.e. new nodes or terms cannot be added to a template.
>
> Ian
>
> Dr Ian McNicoll
> office / fax  +44(0)1536 414994
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
>
>
> Clinical analyst, Ocean Informatics
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care SG Group www.phcsg.org
-- next part --
An HTML attachment was scrubbed...
URL: 

GUI-directives/hints again (Was: Developing usable GUIs)

[Koray Atalag]

Hi Ian, others

We've had a bit of discussion on this at Medinfo and that you pointed to 
separation of pure GUI stuff from others where there is an inherent 
relationship with the semantics and structure of information - fully agree.
The question is how to do that and when; i.e. the process. I think the time is 
just about right as implementations start and progress rapidly. As to how I 
think having these discussions is a great start. But it'd be great if someone 
from the core group 'owns' this thread and puts some pressure on us.

As Ian pointed out we have some 10 directives, which turned out to be all 
generic (i.e. not specific to our endoscopy application) which is great. The 
isCoreConcept directive really is a special one which deeply involves semantics 
and structure of the clinical information being modelled. Rest of the 
directives are not so much like this but there is an obvious need to separate. 
The mantra of openEHR modelling says that anything that has to do with 
structure and semantics goes into clinical models. Then which models? I think 
we must first make clear what we are talking about: out of models or within 
models and then Archetypes or Templates. 

For us this was a no brainer because I think ALL pure GUI stuff should go to 
Templates. I have explained my reasoning in a previous message but shortly 
archetypes and templates are all about information capture and validation (i.e. 
which data items, their organisation, and basic constraints for validation). 
Real world semantics are delegated to terminology (i.e. heart murmur IS-A 
symptom of heart disease or cardia is PART-OF stomach etc). I think we need to 
keep archetypes fairly pure and generic with large scale interoperability in 
mind. However templates provide all the convenience needed otherwise. 

I strongly believe we do_not_need another layer of modelling for GUI because 
referring back to my definition of clinical models, these are to do with 
information capture and validation...And that's what GUI is tightly coupled 
with this. Our models are designed for change; indeed this is the very reason 
we split into multi-levels. So maintaining two different models serving similar 
purposes is not good modelling design I think. At least that wouldn't work for 
us with >3000 lines of ADL plus 9 language translations x 10 archetypes and 
many others...The mode of change has to be together; that is when I am making a 
change to an archetype or template I must immediately take care of its GUI 
behaviour.

That said, returning back to Ian's suggestion, other directives should probably 
be incorporated into templates and really hard ones into archetypes. For 
example we need some means to depict whether a clinical finding (aka core 
concept) is present or not I had to introduce an extra ELEMENT to each and 
every node of my MST archetypes. The flavours of null on ELEMENT is not 
sufficient for that and after all it has to be depicted at CLUSTER level. 
CoreConcept is also another one, perhaps need an abstract ITEM over CLUSTER and 
ELEMENT just to provide that semantics. We have studied this core concept stuff 
in detail and I also have substantial amount of practical experience on this. I 
must say that we drew the line by referring to Astrid van Ginneken's work - 
openSDE (from Erasmus Univ). There are REALLY good GUI related stuff there 
which openEHR can benefit - I have been saying this for long! The key phrase is 
whether you can talk about absence of something or not - if you can then it is 
a core concept which needs special attention in modelling.

http://opensde.sourceforge.net/


Here is the link to our original paper on the GUI Directives and how we 
implemented:
http://openehr.org/wiki/download/attachments/18513934/Atalag_HINZ2010-Paper.pdf?version=1&modificationDate=1291667587000

This is also another recent paper came out of the same study which mentions 
about implementation strategy including GUI stuff:
http://openehr.org/wiki/download/attachments/18513934/Atalag_1_5.pdf?version=1&modificationDate=1291667587000


Hope stimulates more discussions...

Greetings from Auckland :)

-koray

Skype: atalagk



-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Ian McNicoll
Sent: Tuesday, 7 December 2010 1:14 a.m.
To: For openEHR technical discussions
Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs)

Hi Olof,

I agree but I think there are some directives that are actually not
purely GUI directives but which say something meaningful about the
underlying information.

For instance Koray's directive

isCoreConcept (g): "This is an abstract concept; but we can say that
Core Concepts are real-world entities which we can talk about their
abscence (i.e. a clinical finding, a disease but not tumour grade or
physical examination). The directive depicts whether a node with all
its children (if any) shall be handled and repeate

GUI-directives/hints again (Was: Developing usable GUIs)

[Koray Atalag]

Hi All, late to respond but here are a few thoughts:


-  While having ?another layer? of modelling to handle presentation I 
think we already have enough of those layers. I believe the common sense of 
doing this will be to sort out the GUI Directives stuff we all have come up 
with and do a careful analysis (led by the core team of course). Decide which 
ones are ?universal? and which ones are data-set specific. Then like 
annotations in templates invent new optional keywords to accommodate these. The 
operational template will then contain everything an application would need to 
function.

-  I strongly believe that the presentation information should not be 
separated from data-set definitions ? templates. As archetypes and templates 
are designed to handle ?change? this means that the model will be on constant 
change so maintaining two models ? kind of shadows of each other does not make 
sense to me. Perhaps not so good design from a puristic point of view ;)

-  I am also pretty sure that with a handful of those GUI directives we 
can cover %80 of all presentation requirements in any clinical domain ? we?ll 
worry about the rest later on. So it may well be the case that some of these 
directives may become concrete and be part of the specifications ? which will 
boost consistency among different implementations.

-  I also think while thinking on these issues we should also have a 
look at other facades of GUI ? such as implementation technologies, Web/client 
forms and MVC etc. methodologies. These may have an influence on the directives 
we will likely to come up with.

My 4 cents...Cheers,

-koray

P.S. Our developer Mr. Hong Yul Yang (also an awesome pianist!) now has a good 
understanding of openEHR and I think he has much to contribute to this 
community...he gave a good deep thought to the above implementation 
technologies and MVC approach before going on with GastrOS. Hong Yul I think it 
is now time to talk for yourself ? don?t be shy! And people don?t hesitate to 
ask all your hard questions...

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: Thursday, 2 December 2010 2:45 p.m.
To: openehr-technical at openehr.org
Subject: Re: GUI-directives/hints again (Was: Developing usable GUIs)

On 02/12/2010 01:33, Tim Cook wrote:

On Thu, 2010-12-02 at 00:50 +, Thomas Beale wrote:




This is one of the most common uses of templates we are finding.



So somehow knowing the possible choices somehow affects the actual code

in the field you are querying?

in theory no, but it could affect what you consider to be correct. If you knew 
there were only 3 possible codes due to a template that had been used, then you 
might query directly using those codes, rather than the 20,000 allowed by the 
archetype.



I can imagine other thing, e.g. coding of fields that were just

DV_TEXT in the archetype.



While I still think that this is a bad idea anyway.  After all; it is

either free text or coded text.  Pick one. I still don't understand how

knowing what set was available is meaningful to the code chosen.

well the user often picks whether to code or not; a quite common visual control 
is one that allows either to be entered. So the template might define a 
preferred value set of codes, while still allowing for plain text. The 
archetype probably only had the plain text constraint. If you have the template 
at hand, you could do some querying based on the knowledge of the code subset 
used by the template.



In ADL 1.5-land, a template is just another layer of archetyping, with

some extra features.



I still fail to see the need.  It seems to me to be a useless layer of

complexity.  But, I am still interested in a use case where templates

are 'needed' to 'fully interpret' the data.

you mean the need of having the template to interpret the data? You can 
undoubtedly do it without the template. But since a lot of coding is defined 
locally, I think it is going to turn out to be useful.



This is distinct from any 'visual template' stuff, which I agree

should be a distinct artefact and probably formalism.



And this level is dependent on implementation choices.  Only

applications built using the same framework can share these templates.

If an entity is going to dictate presentation options and layout then

they are likely (IMO) going to do so in the context of the same

framework.

sure. This would imply yet another technology-independent formalism, if gui 
directive templates are also going to be portable.

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

More on ISO 21090 complexity

[Koray Atalag]

Hi All, what a discussion :)

Just a few points: we have developed an endoscopy reporting application based 
on a very comprehensive domain model (some of you already know - I am obsessed 
with this model!) using openEHR specifications. There were many obstacles - 
including data types (for example a quantity data type with two alternate units 
of which one was not in the list of selectable units defined in a small 
terminology) but a solution could always be found. I can say that it has worked 
for us and in a few weeks time we will release the code as open source. There 
was a mention of GUI with data types; indeed I must say that they almost always 
dictate the type of widget on screen - that's our experience. Rest of the GUI 
definition comes from what we call "GUI  Directives" inserted into Templates as 
annotations. I suggest that we define a specific entry for GUI for each node at 
template level.

There relevance of this message to this thread is that, I have repeated this 
argument several times before, I suggest working on some concrete examples when 
discussing about pros and cons of different standards. So I'd be very 
interested to see some examples (caution not to use 'use case' here ;) where 
one standard data type works and the other doesn't and vice versa. Perhaps a 
wiki page where the ordinary readers like me could understand fully and 
appreciate the many arguments thrown so far. It's a pity that we are using so 
little of the available e-collaboration tools effectively while calling 
ourselves as (health) informaticians ;)

I personally think we, health informaticians, make life a lot more complicated 
than it should be. I am pretty confident that the solution of >90% of problems 
is a no brainer and that we need more of it for the remaining. My gut feeling 
is that the chances of getting something working out there are higher if we 
start with simple and generic data types. Based on the needs during 
'real-world' implementations (not well thought use cases) I think they can 
evolve 'incrementally'. I must admit that I may just be too simplistic here but 
this is my approach to solve problems.

There were also a few mentions about 'maintainability' and 'software quality'. 
Well I know a little bit about this (indeed my research is all about this 
topic!). Maintainability, according to the well accepted ISO/IEC 9216 and 25000 
series standards quality model, is a quality characteristic - a very important 
one because it has a dramatic effect on software cost. The rule of thumb is to 
avoid complexity - in code, design artefacts, process etc. The preliminary 
results of our research shows that it takes seven times less time to implement 
changes and the complexity is nine times less in the openEHR based application 
compared to a 'typical' object-procedural/relational DB application. One next 
research question now in my mind is to build a third application using HL7 
based on exactly the same requirements. I'd be very keen to collaborate if you 
find the idea interesting and worth investigating. I guess this should then be 
the "Evidence based health informatics" ??

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Seref Arikan
Sent: Sunday, 21 November 2010 6:50 a.m.
To: Dr Lavanian; For openEHR technical discussions
Subject: Re: More on ISO 21090 complexity

Greetings,
I'd say that simplification is a must in medical informatics, but I would not 
attempt to bring that simplification to the standards or the scope of medical 
informatics.
The level of detail and complexity we introduce into our solutions is there 
because most of the time, even with the best practices history has thought us, 
there is a certain amount of complexity we can not avoid.

As long as the requirements are in the lines of  "connect every hospital, every 
information system, every mobile device to healthcare data.." there will be 
these endless versions
Where we need simplification is the front end of the technologies we are 
developing. That is tooling and clinical systems and other outputs, pretty much 
anything that relies on standards and software development.

the real challenge in medical informatics IMHO is to give a doctor something 
that feels at least as convenient as the A4 sheet of paper and does at least a 
little bit better. I personally do not think that this is necessarily a 
challenge completely linked to the underlying complexity of the standards or 
information systems. There is certainly a connection, but complex 
specifications on their own are not reason for still not having the solutions 
we have been dreaming about.

If you try to reflect the requirement of a layer onto others, you'll almost 
always end up losing capability. In fact, the price of power and simplicity is 
most of the time increased complexity at the background. For example, any 
expensive car with an F1 style gear shifting gives you a much simpler 

What does "Add reference" in Archetype Editor means

[Koray Atalag]

Privet Igor, this simply creates an "internal reference" to that node which you 
can reuse in upcoming parts of the same archetype. Of course the at code at the 
very end is referring to the same term_id. But the paths are difference 
depending on where it is referenced. Look at the 'internal reference' section 
or search for "use_node" within the ADL spec. I use it heavily where there are 
multiple appearances of a certain data node with exactly same semantics (i.e. 
anatomical sites) that needs qualify lots of "findings" which require further 
qualification of anatomical sites. When you create this reference using 
Archetype Editor you can drag and drop into onto any other part of the model. 
In the end when an operational template is generated there is no longer any 
difference between the 'referenced' and the 'referencing' nodes; i.e. they all 
become the same description of the same data item.

Hope this helps...You can look into the archetype: 
openEHR-EHR-OBSERVATION.MST_colon.v1
Which used to come bundled with the AE installation.

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of ? ???
Sent: Tuesday, 6 July 2010 6:21 a.m.
To: openehr-technical at openehr.org
Subject: What does "Add reference" in Archetype Editor means

Hi!

When right-clicking on any element in Archetype Editor there is link "Add 
reference" which adds a readonly element to definition.

So, what does it mean?

--
Best regards,
Igor Lizunov
-- next part --
An HTML attachment was scrubbed...
URL: 

Governance of terminology lists

[Koray Atalag]

Hi Ian, I guess this topic is not of great interest at the moment :(
It's be great to have feedback though...Perhaps I'll discuss this offline.

Cheers,

-koray


From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Ian McNicoll
Sent: Monday, 17 May 2010 11:18 p.m.
To: For openEHR clinical discussions; For openEHR technical discussions
Subject: Governance of terminology lists

In a separate thread Koray suggested:

"... do you think it would also be a good time to discuss the cases where some 
custom defined/non included units need to be added for some properties in 
DV_QUANTITY. You may remember our discussions around 'French' as Gauge unit - 
which is not allowed currently. Although this may safely be added to 
terminology I think many more will follow when people really get into niche 
highly structured  clinical modelling."

which raises a more general issue of governance arrangements for the openEHR 
terminology and associated Amount properties terminology. There has been some 
discussion, and I think consensus about using the Java implementation 
terminology definitions as the source of truth, but the issue remains as to how 
changes to these definitions and the properties definitions are to be managed, 
including translation.

We need to have clear lines of communication and responsibility for acting on 
requests to update these terminologies. A number of possibilities exist but I 
wonder if this might not be usefully carried out within CKM, which has high 
visibility, and mechanisms for editorial control and review. Request's like 
Koray's will be reasonably common - we need to establish a reliable mechanism 
for handling these, and changes to UCUM etc

I would be interested in other suggestions - the 'delivery' mechanism wiki, svn 
, CKM etc is less important than the governance / review process behind it. I 
also feel this is primarily a technical activity but will probably need somre 
clinical input as a sanity check.

We also need to think about these issues in relation to possible alignment with 
IHTSDO e.g should we start to think about using SNOMED-like primary technical 
representations.


Regards,

Ian
Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
ian at mcmi.co.uk

Clinical Analyst  Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / 
BCS Health Scotland
-- next part --
An HTML attachment was scrubbed...
URL: 

Specialisation of archetype - Some doubts

[Koray Atalag]

Hi Moretti, I noted similar problems and discussed with Tom. He suggested that 
we create a PR.
Here is another problem:

AE allows in specialisation setting occurrences higher than defined in parent 
(with ELEMENT I have tested).
So do you want to go ahead and raise the PR issue?

Cheers,

-koray


-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Moretti Leonardo
Sent: Wednesday, 19 May 2010 11:26 p.m.
To: openehr-technical at openehr.org
Subject: Specialisation of archetype - Some doubts

When we specialize an archetype, we must keep in mind some rules as:
- a specialised archetype can only further narrow existing constraints 
in the parent (but it may add its own)
- constraints are inherited, and can be overridden
- overrides are ?covariant?, i.e. the constraints are narrower than the 
parent, also can be thought of as ?subsumed?
- new constraints can be added where allowed by the parent archetype and 
reference model


Using Archetype Editor I noted some strange behaviours, and I don't 
understand if they are bugs or a my misunderstanding of specs:
1) I can modify an inherited constraint (changing the text on 
term_definitions, the occurrences or the cardinality) without specialize 
the constraint (the archetype node id is the same of the parent 
archetype).. I thought we should specialize a constraint to modify it!

2) when we specialize a cluster with max occurrences > 1, a new 
constraint is created and all children are deleted (why?)

3) can we delete an inherited constraint? if this is an Element we can 
do it with Archetype Editor, specializing it and the deleting it. This 
is not possible for Cluster

Many thanks in advance for any comments.

Best regards,
leo

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Medinfo 2010 openEHR tutorial collision

[Koray Atalag]

Resending as plain text - bounced back due to file size when I replied

-
Hi, so it looks we are definitely going to have the clinical modelling workshop 
on Saturday.

Looking at the discussions between Tony and Heather I note that there is an 
agreement on finishing up the workshop by demonstration the whole continuum of 
requirements>modelling>design>development. I totally agree. Indeed we haven't 
yet discussed about individual presentations but this is how I had in mind 
about my presentation. I will start with the requirements for archetype 
modelling in endoscopy domain, then present archetypes and the final template 
which will then be followed with demonstration of our .Net/C# openEHR 
implementation of an endoscopy report generator application with an emphasis on 
GUI aspects. I also want to touch software maintainability as a merit of 
modelling using openEHR. I think this flow fits well into what you think.

Perhaps we should all start discussing how to design the whole workshop. 

Cheers,

-koray


From: openehr-clinical-bounces at openehr.org 
[mailto:openehr-clinical-boun...@openehr.org] On Behalf Of Heather Leslie
Sent: Friday, 14 May 2010 5:43 a.m.
To: Shannon Tony (Leeds Teaching Hospitals NHS Trust)
Cc: For openEHR clinical discussions; For openEHR technical discussions
Subject: Re: Medinfo 2010 openEHR tutorial collision



On 13/05/2010 1:10 PM, Shannon Tony (Leeds Teaching Hospitals NHS Trust) wrote: 
Thanks Heather
?
Sounds good, though my?sense is that?if the "clinical" workshop appears to have 
been allocated 6?hours (1.5 x4) and the?"technical" (developers)?workshop has 
1.5 hours on Monday, there will be attendees on the Saturday that will want to 
get into the technical detail you want to avoid?
I know it is 'not fair' but I'm not sure that we can change the scope of the 
accepted proposal in order to even it out. ? I understood that the accepted 
workshop paper will be published and so we cannot change at whim, especially in 
terms of the expected audience and expected learning outcomes.? I'm happy to be 
corrected...

As I've said previously, I think that we do have some room for flexibility in 
the final session and certainly a willingness to do so.

?
As the Saturday sessions are currently labelled openEHR I- IV in the 
"draft"?programme?we should be asking the organisers to?amend the session 
titles to avoid confusion..
We can certainly request that.

Building?overlap between the final "openEHR in action" session on the Saturday 
and the developers session on the Monday sounds a good way to align.
Absolutely

?
Awaiting some reaction from the technical side
me too;-)

?
Regards
?
Tony
?

From: Heather Leslie [omowizard at gmail.com] On Behalf Of Heather Leslie 
[heather.les...@oceaninformatics.com]
Sent: 13 May 2010 13:43
To: Shannon Tony (Leeds Teaching Hospitals NHS Trust)
Cc: For openEHR clinical discussions; For openEHR technical discussions
Subject: Re: Medinfo 2010 openEHR tutorial collision
Hi Tony

On 13/05/2010 9:17 AM, Tony Shannon wrote: 
Thanks Heather

I see from the "clinical" proposal how the 4 sessions on the Saturday
are to be split...
Session 1: Introduction
Break
Session 2: Focus on Archetypes
Lunch
Session 3: Focus on Templates
Break
Session 4: openEHR in action
My reading of this is that there will be a mix of clinical and technical
  language used to step through these sessions,
As primary author, the original intent was to be focused on the engagement of 
clinicians and those with no openEHR background - a primer if you like - and to 
keep the technical content to a practical minimum, assuming that there would be 
an equivalent technical opportunity.
Now that has not eventuated but as I said in the previous email, I need advice 
as to how much we can move from our accepted proposal - I suspect we are 
largely bound to it as is, but can see the flexibility to present more 
technical aspects within the context of the final session - openEHR in action.

 which if done well
should be fine.

#Suggestion #1
Within the clinical workshop, I expect novice clinicians to come with a
common clinical requirement in mind and be keen to see how that ends up
at the UI layer, where the vast majority of clinicians meets the
technology..
ie
1.Assume we should be taking a common requirement, eg Patient Summary
2.explore related archetypes required, eg in CKM
3.creation of related template
4.exposure of said template at UI layer..
  
This is largely what was proposed as part of #3 - after a general introduction 
in session #1, and information about archetypes/CKM in #2, then we can showcase 
the templates with a practical example such as you suggest in #3

(While I'm cc'ing the technical list in here, how much technical debate
do the technical community expect will be generated by this "clinical"
proposal?
The current state of the template spec and the challenge of translating
archetypes and templates into the UI layer c

Setting up a common publication/resource library for openEHR

[Koray Atalag]

Hi Ian, yes I was pointing out to Zotero because I have been using it since a 
year now and every time I use it my admiration grows. I do not use such strong 
expressions to many software - including some openEHR tools ;)

Sebastian yes I think we should only store meta-data about citations publicly 
with URL's to full text. Then the people who has access (through their 
institution or personal account) can also download it with a single click. I 
checked the ZOtero site more carefully after I sent my message and found out 
that this is indeed provided by ZOtero freely - that is free hosting of 
meta-data and group access.
A quick experiment: http://www.zotero.org/groups/openehr/items


For those that are interested please contact me offline and I'll provide you 
with instructions.

Cheers,

-koray

From: openehr-technical-bounces at chime.ucl.ac.uk 
[mailto:openehr-technical-boun...@chime.ucl.ac.uk] On Behalf Of Ian McNicoll
Sent: Monday, 15 February 2010 10:00 p.m.
To: For openEHR technical discussions
Cc: For openEHR clinical discussions; For openEHR technical discussions
Subject: Re: Setting up a common publication/resource library for openEHR

I would definitely recommend Zotero - this is what I use to store and format 
the references used in CKM. Mendeley looks very interesting, and perhaps better 
suited for joint reference libraries, but they do recognise that it is not as 
fully-featured as Zotero.

Ian

Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com<mailto:ian.mcnicoll at 
oceaninformatics.com>
ian at mcmi.co.uk<mailto:ian at mcmi.co.uk>

Clinical Analyst  Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org<http://www.phcsg.org> / 
BCS Health Scotland


On 15 February 2010 08:08, Sebastian Garde mailto:sebastian.garde at oceaninformatics.com>> wrote:
Hi Koray,

did you have a look at Mendeley http://www.mendeley.com/ ?

I haven't checked it out yet in detail yet, but it looks promising.
They have sufficient clout to make it happen (they are the skype people)

Some of the papers unfortunately cannot be made available on the openEHR 
website due to copyright limitations - depends on the journal (and sometimes 
the time passed since publication)

Cheers
Sebastian


Koray Atalag wrote:
Hi All,

Whenever I start with a paper, report  or presentation I find myself doing the 
same literature search and environment scan...And can only find the ones that I 
can or allowed to access. I am pretty sure this is the case for many of you out 
there. The current publications page on openEHR Website is quite limited and 
not frequently updated. What about creating a wiki page or a common bookmarking 
system?

If there is enough enthusiasm (if any), I also suggest that we look at the 
Zotero Open Source project. It is extraordinary (believe me!) high quality, 
works as a plug-in to Firefox which is FOSS and a much better form of End Note. 
It is possible to create a repository (only-meta data with links to full-text; 
requires WebDAV) that we all can share and update.
Look: www.zotero.org<http://www.zotero.org>

So I am willing to start it if your voice is strong enough ;)

Cheers,

-koray


___
openEHR-technical mailing list
openEHR-technical at openehr.org<mailto:openEHR-technical at openehr.org>
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100216/014cae72/attachment.html>

Setting up a common publication/resource library for openEHR

[Koray Atalag]

Hi All,

Whenever I start with a paper, report  or presentation I find myself doing the 
same literature search and environment scan...And can only find the ones that I 
can or allowed to access. I am pretty sure this is the case for many of you out 
there. The current publications page on openEHR Website is quite limited and 
not frequently updated. What about creating a wiki page or a common bookmarking 
system?

If there is enough enthusiasm (if any), I also suggest that we look at the 
Zotero Open Source project. It is extraordinary (believe me!) high quality, 
works as a plug-in to Firefox which is FOSS and a much better form of End Note. 
It is possible to create a repository (only-meta data with links to full-text; 
requires WebDAV) that we all can share and update.
Look: www.zotero.org

So I am willing to start it if your voice is strong enough ;)

Cheers,

-koray

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

Fw: Interoperability with HL7

[Koray Atalag]

Hi All, interesting discussions but I am afraid it does not take use anywhere...

Yes we all need (we=all of us) some better means to develop health information 
systems; not only limited to EHR space but the whole continuum including the 
long waited clinical applications which would help doctors and other healthcare 
professionals make informed decisions etc. etc.

I think what we are all up to is first a solid methodology to build better 
systems - no brainer ha?
OK look at other domains, well technical mostly, Telecom, Tourism, Marine, even 
Entertainment and eGovt. As far as I know (I may be slightly wrong though) 
neither of these is based on "special home delivery" standards, BUT have 
adopted development methodologies which worked for everybody - ultimately 
benefiting the consumer. Why on earth we are going down this pathway? It is 
absolutely silly to have all these standards in same direction with slight 
differences. I don't understand how public money is spent so irresponsibly

Why don't we just build systems with what we have and then drive the 
standardisation process with real evidence...an evolutionary rather than 
regulatory path. As a developer myself when I see ISO, CEN etc. imposing 
constraints on me just because they are strong and have powers I feel offended. 
How many of those people have really built systems, or let alone sat at the 
same table with clinicians to talk about what they need, gone through 
procurement processes with RFP's that don't even mention about 
interoperability? I wonder...

Having said these, I will soon publish the results of my research on software 
maintainability of openEHR based vs. classical OO/Procedural with RDMS model by 
building a full working application with C# .Net. The implementation is almost 
complete and I am expecting to have initial results by March. So let's see if 
openEHR really works and future-proof! These will be quantitative evaluation 
results by employing formal software measurement.

We need evidence gentlemen, why don't we focus on that first. IP is nonsense 
wrt. Archetypes and openEHR and everybody knows that.
So what are the vendors and governments waiting for??? EVIDENCE!!!


Cheers,

-koray

From: openehr-technical-bounces at chime.ucl.ac.uk 
[mailto:openehr-technical-boun...@chime.ucl.ac.uk] On Behalf Of Bert Verhees
Sent: Thursday, 11 February 2010 2:08 a.m.
To: For openEHR technical discussions
Subject: Re: Fw: Interoperability with HL7



It is imperative that DCM's are absolutely free to use and in the public 
domain. CEN/ISO and ANSI assure that with the standardisation IP rules in 
general.
DCM's must be absolutely free from IP problems, well maintained in a formal, 
flexible, organisation, owned and controlled by all that use them.
OpenEHR as we know it today is a private company. (See under Status: 
http://www.openehr.org/about/foundation.html)
It is not the juridical status of a company that makes the difference for the 
IP-status of something. If an organization is not-for-profit or for-profit, 
both can issue all kinds of IP-licenses.
The company form has nothing to do with the licenses it issues

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

openEHR community on Google Wave

[Koray Atalag]

Hi All, 

I don't understand how the terms "vendor lock-in", "behind doors" etc. are 
associated with Ocean - I see it as a social service organisation rather than a 
commercial entity by the way :P

Interesting times ;) Though I am hoping that we can identify the underlying 
reasons why some of us got so much sensitized and discuss this openly...

Cheers,

-koray


-Original Message-
From: openehr-technical-bounces at chime.ucl.ac.uk 
[mailto:openehr-technical-boun...@chime.ucl.ac.uk] On Behalf Of Sam Heard
Sent: Thursday, 3 December 2009 6:20 a.m.
To: 'For openEHR technical discussions'
Subject: RE: openEHR community on Google Wave

Hi Erik
Can you tell me what search capabilities you want in CKM that are not there.
You can export a prot?g? ontology, all the archetypes and have all the
search power we have thought of from the asset management platform.
Unsearchable seems a little unfair.
Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at chime.ucl.ac.uk [mailto:openehr-
> technical-bounces at chime.ucl.ac.uk] On Behalf Of Erik Sundvall
> Sent: 19 November 2009 09:35
> To: For openEHR clinical discussions
> Cc: For openEHR technical discussions
> Subject: Re: openEHR community on Google Wave
> 
> Hi!
> 
> On Thu, Nov 19, 2009 at 06:48, Heather Leslie
>  wrote:
> > If I have caused any confusion, I apologise. I'm just enthusiastic
> and
> > interested to further explore the potential (or not) offered by
> Google
> > Wave.
> 
> It is a very nice initiative Heather and there is no need to
> apologise, just a need to get the discussions out in open public
> searchable space (and that also goes for the currently unsearchable
> CKM).
> 
> I believe that in a set of properly managed wave conversations it
> might be easier to follow the discussion flow, and it might be a less
> fragmented user experience than the current CKM is. If done right and
> when there are more wave providers than Google (since wave uses a
> truly open protocol) then we could at the same time get rid of the
> current CKM vendor lock-in and extension limitations (without creating
> another vendor lock in).
> 
> > While these initial 'coordinating waves' are public, small groups may
> go off
> > and use a private Wave to work on a task or project - just like they
> do now
> > using email, skype or IM.
> 
> Yes of course some conversations (or parts of conversations) will
> always be private since humans prefer to work that way sometimes. The
> problem is if things are inaccessible and unsearchable even when there
> is no intention to keep the discussion private.
> 
> > The result should be identical - submitting the
> > draft archetype to CKM or contributing to the email lists or wiki.
> 
> If wave-based tools become widespread and powerful enough to do
> openEHR review, voting etc., then I don't see CKM as a necessary step
> in the pipeline to finally submitting archetypes/templates to simple
> stable repositories. Every shift of tools along the way adds a
> potential user confusion.
> 
> By the way, have you tried using mindmapping gadgets for openEHR
> related development in wave, I found an open source mindmapping gadget
> that even includes a voting mechanism and freemind-import facilities
> at:
> http://wave-samples-gallery.appspot.com/about_app?app_id=64007
> See also: http://www.brucecooper.net/2009/11/mind-map-gadget-for-
> google-wave.html
> And since the mindmapping gadget is open source it could easily be
> modified by any java/GWT developer to add features that you'd find
> useful for openEHR related use :-)
> 
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
> (Mail & tel. recently changed, so please update your contact lists.)
> 
> P.s. To add voting to suitable items (e.g. corresponding to when you
> use voting in CKM) it seems like
> http://wave-samples-gallery.appspot.com/about_app?app_id=23006 might
> be useful. I guess a proper discussion will often solve things without
> the need for voting though...
> ___
> 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

Rong Chen PhD thesis online

[Koray Atalag]

Well done Rong - you fully deserved the degree :) 

Cheers,

-koray

-Original Message-
From: openehr-technical-bounces at chime.ucl.ac.uk 
[mailto:openehr-technical-boun...@chime.ucl.ac.uk] On Behalf Of Thomas Beale
Sent: Tuesday, 1 December 2009 3:07 p.m.
To: Openehr-Technical; For openEHR clinical discussions
Subject: Rong Chen PhD thesis online


Rong Chen, the original author of the openEHR Java implementation has 
finally returned to mainstream humanity, after completing his Doctoral 
dissertation. The abstract and link can be found here: 
http://www.openehr.org/shared-resources/publications/archetypes.html .

An abstract from the abstract:

The key contribution of the thesis can be summarized as the validation 
and further improvement
of the openEHR archetype formalism through software implementation and 
the explorations on
clinical guidelines, shared care plans and legacy EHR content models in 
relation to archetype-based
EHR framework.

congratulations Rong!

- thomas beale

___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

informal poll: openEHR conference

[Koray Atalag]

Hi Tom, having such a social get together would be very niceI'd vote for 
Amsterdam :)

Cheers,

-koray

From: openehr-technical-bounces at chime.ucl.ac.uk [openehr-technical-bounces 
at chime.ucl.ac.uk] On Behalf Of Thomas Beale 
[thomas.be...@oceaninformatics.com]
Sent: Sunday, 29 November 2009 8:57 a.m.
To: For openEHR technical discussions
Subject: Re: informal poll: openEHR conference

I forgot to mention: personally I would like it to be an environmentally 
conscious event (in as much as any conference could be), and one thing I would 
at least try for is a destination that allow many people to go by train rather 
than by plane. Sam and I once did London - Maastricht (which by the way is also 
a good location) on the train in 7.5h (1.5h wait in Brussels) compared to what 
we calculated as 5h by plane. But we got 6h work done, and 1h drinking Belgian 
beer. I consider that a successful journey. Of course not much can be done 
about long haul flying from the US and down-under.

Another priority for me would be the idea that it would not repeat every few 
months like standards meetings, maybe not even every year (a bi-annual event 
maybe?) - so we could afford to spend some time together as a community. Also, 
I would put as much value on the networking and social side of things as on the 
'business of openEHR' - which means finding a nice destination, one that works 
perfectly well if people want to have a holiday, with kids, partners etc.

The cost might also be an important consideration for most people, although if 
it were say every 2 years, it may not matter as much as for standards meetings 
which just keep happening.

these are just personal thoughts; it could only happen if enough people in the 
community would sign up to the idea to make it viable.

- thomas beale


Mikael Nystr?m wrote:
I guess that the social activities would be quite important for the community 
and they are hard to organize on airports and train stations. I therefore vote 
for other locations than airports and train stations.

  Greetings,
  Mikael


From: openehr-technical-bounces at 
chime.ucl.ac.uk 
[mailto:openehr-technical-boun...@chime.ucl.ac.uk] On Behalf Of Bert Verhees
Sent: den 27 november 2009 17:38
To: openehr-technical at openehr.org
Subject: Re: informal poll: openEHR conference

An international airport/train station nearby would be good, it saves days of 
traveling.

Bert

Op 27-11-09 17:25, Thomas Beale schreef:

This is an initial informal question to the community about interest in an 
openEHR conference / meeting, probably initially located in Europe. Possibly 
activities:

 *   presentations / papers on commercial & academic projects
 *   technical working design sessions for major upcoming specifications
 *   clinical modelling design sessions / presentations / discussions / debates
 *   meetings aimed at making decisions about the running & governance of 
openEHR, enabling future organisational improvement
 *   professional and academic networking activities
 *   some purely social activities.
purely as an example of a nice location at which social and outdoor activities 
can take place, Lake Bled in Slovenia has been suggested, of course there are 
many other wonderful locations. I have heard many requests for a conference 
over the last few years, so I wonder what the reaction & interest of the 
community to this suggestion would be.

- thomas beale








___

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



--
[cid:part1.05030002.04040909 at oceaninformatics.com]  Thomas Beale
Chief Technology Officer, Ocean Informatics

Chair Architectural Review Board, openEHR Foundation
Honorary Research Fellow, University College London
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog

Where can I download the OpenEHR terminology?

[Koray Atalag]

Hi Pablo, yes I tried and got the same response as well...However I found one 
(I guess an earlier version) that comes with the Ocean Archetype Editor; search 
the installation directory.

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of pablo pazos
Sent: Tuesday, 3 November 2009 7:11 a.m.
To: openehr technical
Subject: Where can I download the OpenEHR terminology?

I've tried the link from here: 
http://www.openehr.org/releases/1.0.2/architecture/computable/terminology/terminology.html

But points to: 
http://www.openehr.org/releases/architecture/computable/terminology/terminology.xml

And I get a 404.


Thanks a lot.

Pablo.
http://pablo.swp.googlepages.com/


Windows Live: Make it easier for your friends to see what you're up to on 
Facebook.
-- next part --
An HTML attachment was scrubbed...
URL: 

CKM Icons

[Koray Atalag]

Hi All,

I remember Ian doing some work on the set of icons for the purpose of using in 
mindmaps...I wonder if they can be reused. Any idea Ian?

Cheers,

-koray

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Lisa Thurston
Sent: Thursday, 22 October 2009 2:27 p.m.
To: For openEHR technical discussions
Subject: Re: CKM Icons

Thomas Beale wrote:
there have been discussions in the past about creating a nice set of icons for 
general openEHR use across all tools and documents (or possibly various 
alternative sets). If there are people out there with the relevant skills and 
time, I am sure the community would be greatly helped by the production of 
better icons.

- thomas beale
Just wonderinf if there is a text list of icons required and their 
corresponding meanings? That would serve the dual purpose of being a legend for 
the current icons and being a set of basic requirements for an icon designer.

Regards
Lisa


--

Lisa Thurston

Phone +61.8.7127.5574

Skype lisathurston



Ocean Informatics Pty Ltd

Level 4, 25 King William Street

Adelaide SA 5000



http://www.oceaninformatics.com
-- next part --
An HTML attachment was scrubbed...
URL: 

Documentation Desparation

[Koray Atalag]

Hi Roger,

I'd really like the kind of functionality you describe and it is 
definitely desirable...I was little concerned about the workload 
implications to already supersaturated core members. And I must say 
worried about the wording in subject of the thread - the content and 
quality of openEHR documents look pretty satisfactory to me at the 
moment. Sorry if my message has been little "reactive" - but I can not 
help but become emotional when it comes to openEHR ;)

BTW I'd be very interested to know if anyone prefers to use a "text 
editor" when creating/updating archetypes? It'd be very cool to have an 
"ADL" aware editor and have kind of "intellisense" functionality for 
writing ADL expressions for advanced users.

Cheers,

-koray


Roger Erens wrote:
> Hi Koray,
>
> If you imagine some sort of workbench or platform that can be used to 
> create openEHR-based applications, wouldn't it be nice if the 
> workbench would offer the creator/developer some sort of help along 
> the way? Not with tooltips saying something like "See the reference 
> documentation" but more like tooltips containing snippets of the 
> reference documentation, e.g. "Insert here an object of type DV_TEXT: 
> ". If you envisage this workbench 
> or platform in a web-centric setting, it's not too hard to see that a 
> translation service (Yahoo's or Google's) could machine-translate 
> those snippets. Of course it should be very clear that the originally 
> published (English) specification on openEHR.org is authorative.
>
> I think the OP was pointing into this direction, and not a 
> multi-million resource-intensive translation process.
>
> From-the-pitfalls-yours,
>
> Roger
>
> On Sat, Sep 26, 2009 at 03:23, Koray Atalag  <mailto:koray at cs.auckland.ac.nz>> wrote:
>
> Hi All,
>
> I really appreciate the "mental" exercise to achieve a better
> documentation; however I must say I am really surprised to watch
> the recent discussions like this one because I wonder if we, as a
> community yet to solve many fundamental problems and overcome the
> many challenges, have enough resources to deal with this at the
> moment. Frankly I disagree with the need to translate all the
> specs and documentation into other languages at the moment - not
> to say that this is trivial but I don't think we are at that stage
> at the moment. And when we become (if ever!) a multi-million $$$
> foundation then I suggest looking at how ISO or national bodies
> approach the multi-lingual documentation problem.
>
> While I believe in and most importantly own a couple open source
> projects myself, I see many from FOSS rounds getting into the
> pitfall of seeing software as either evil or good or having the
> illusion of open source as a merit by itself. That is not true...I
> hope we don't end up trying to FOSS everything "just for the sake
> of" the "open" in our prefix ;)
>
> And ?eref I don't think much people left in Turkey to bother with
> openEHR anyways!
>
> Cheers,
>
> -koray
>
> Seref Arikan wrote:
>> Tom,
>> I'd be happy to help you out, just let me know what you need me
>> to do. I'll be putting all of the documentation into Eclipse
>> plugins of Opereffa anyway. We can turn that task into an
>> experiment to lay out some sort of method for transformation of
>> documentation to other formats.
>>
>> Cheers
>>
>>
>> On Fri, Sep 25, 2009 at 6:08 PM, Thomas Beale
>> > <mailto:thomas.beale at oceaninformatics.com>> wrote:
>>
>>
>> Unfortunately I can't make any conversion mission a top
>> priority, but let's commit at least to an experiment which I
>> can initiate - I will generate the 'standard as-is' XML
>> output from one specification (say the data types) and make
>> that available - Seref or someone else may be able to
>> determine what rules it is following; in the meantime I can
>> do a bit of research on what needs to be done to a FM
>> document to make its XML output DITA based.
>>
>> - thomas
>>
>>
>> Tim Cook wrote:
>>> Hi Seref,
>>>
>>> Thanks for your concerns and well thought out points.
>>>
>>> If you read my original posting, I didn't ask Tom to stop using
>>> Framemaker.  I ask for some output in place of (or in addition to) 
>