RE: Terminology bindings ... again

2017-07-19 Thread 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

2017-05-21 Thread 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 
> 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 
> wrote:

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

Op za 20 mei 2017 10:04 schreef Pablo Pazos 
>:
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 
> 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 
>>
 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=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
pablo.pa...@cabolabs.com>
Subscribe to our newsletter

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

___
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=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
http://www.cabolabs.com


pablo.pa...@cabolabs.com
Subscribe to our newsletter

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

RE: SNOMEDCT - correct representation

2017-05-06 Thread 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á 
> 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 
>:
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.

RE: SNOMEDCT - correct representation

2017-05-03 Thread 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 
<pablo.pa...@cabolabs.com<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 

RE: SNOMED

2016-05-01 Thread 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 licensing, that 
should be looked at.

The 

RE: CAMSS assessment of openEHR

2016-04-11 Thread 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=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 
>
 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=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 

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

2016-03-14 Thread 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


Any work on PHR?

2016-03-06 Thread 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

2016-02-17 Thread 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

2016-02-16 Thread Koray Atalag
;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<tel:+44%20775%20209%207859>
office +44 (0)1536 414994<tel:+44%201536%20414994>
skype: ianmcnicoll
email: 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 
<k.ata...@auckland.ac.nz<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

2016-02-15 Thread 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" 
<i...@freshehr.com<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=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 
<heath.fran...@oceaninformatics.com<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 <i...@freshehr.com<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 
<openehr-technical@lists.openehr.org<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<tel:+44%20775%20209%207859>
office +44 (0)1536 414994<tel:+44%201536%20414994>
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=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 
<k.ata...@auckland.ac.nz<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

2016-02-11 Thread 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

2016-02-04 Thread 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

2016-02-02 Thread 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: [FORGED] Re: Representing microseconds in DateTime

2016-02-02 Thread 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

RE: Representing microseconds in DateTime

2016-02-02 Thread 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

Representing microseconds in DateTime

2016-02-02 Thread 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: [FORGED] Re: [FORGED] Re: Representing microseconds in DateTime

2016-02-02 Thread 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: New EHRServer v0.5 and roadmap

2016-01-14 Thread 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 
> 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

2015-11-30 Thread 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

2015-11-12 Thread 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.

2015-10-12 Thread 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

2015-09-03 Thread 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 
>
 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

2015-08-09 Thread 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.nohttp://arketyper.no/ / Twitter: 
@arketyper_nohttps://twitter.com/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.orgmailto: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 
i...@freshehr.commailto: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.commailto:i...@freshehr.com
twitter: @ianmcnicoll


___

openEHR-technical mailing list

openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org

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

--
[Ocean Informatics]http://www.oceaninformatics.com/

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHRhttp://www.openehr.org/
Honorary Research Fellow, UCLhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCShttp://www.bcs.org.uk/
Health IT bloghttp://wolandscat.net/category/health-informatics/

[View Thomas Beale's profile on LinkedIn]http://uk.linkedin.com/in/thomasbeale


___
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

2015-07-28 Thread 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.commailto: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 Informaticshttp://www.oceaninformatics.com/
Clinical Programme Lead, openEHR Foundationhttp://www.openehr.org/
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

2015-05-25 Thread 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

2015-04-28 Thread 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 
CellMLhttp://www.cellml.org/, 
FieldMLhttp://physiomeproject.org/software/fieldml/about, SBML etc. There are 
semantic tools like SemGenhttp://sbp.bhi.washington.edu/projects/semgen or 
openCORhttp://www.opencor.ws/ 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 luismarco at gmail.commailto: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.orgmailto:openEHR-implementers at 
 lists.openehr.org

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

 penehr.org



___

openEHR-technical mailing list

openEHR-technical at lists.openehr.orgmailto:openEHR-technical at 
lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150428/bcf60a22/attachment-0001.html


Problem-oriented records and querying by problem

2014-11-26 Thread 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 10tel:+47%2093%2043%2029%2010

 Original message 

From: Thomas Beale

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

To: openehr-technical at lists.openehr.orgmailto: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

How to model relationship between archetypes?

2014-10-31 Thread 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 a.anastasiou at 
swansea.ac.ukmailto: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 for this I would recommend that you go
through the Architecture Overview
(http://www.openehr.org/releases/1.0.2/architecture

Texts about transforming between openEHR and other formalisms

2014-10-31 Thread 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 
Zoterohttps://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 Moner, Montserrat 
Robles. XXIII International Conference of the European Federation

Any prep for MIE 2015 in Madrid?

2014-10-31 Thread Koray Atalag
Hi, I was just wondering if there's any activity planned for MIE 
2015http://www.mie2015.es/ 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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141031/2a8c70b9/attachment.html


Ocean's Template Designer and allowedType rules

2013-11-19 Thread 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 heath.frankel at 
oceaninformatics.com 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:



Rule path=/data[at0001]/events[at0006]

   eventConstraint

 allowedTypePointInTime/allowedType

   /eventConstraint

 /Rule



 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

2013-10-17 Thread 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 mate.bestek at gmail.commailto: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 miroslav_koncar at yahoo.commailto: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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131017/e0bcca6c/attachment.html


Recording absence of (clinical) information

2013-07-15 Thread 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.nzmailto:k.atalag at nihi.auckland.ac.nz 
| Web: www.nihi.auckland.ac.nzhttp://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

2013-06-04 Thread Koray Atalag
 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 k.atalag at 
nihi.auckland.ac.nzmailto: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 
Modelhttp://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.nzhttp://www.openehr.org.nz

Koray Atalag, MD, PhD, FACHI
Senior Research Fellow
image001.jpg
School of Population Health, The University of Auckland
Private Bag 92019 Auckland 1142, New Zealand
Email: k.atalag at nihi.auckland.ac.nzmailto:k.atalag at nihi.auckland.ac.nz 
| Web: www.nihi.auckland.ac.nzhttp://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.orgmailto: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


Archetypes at OMG

2013-05-30 Thread 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 
meetinghttp://hssp.wikispaces.com/event-2013-06-OMG-Berlin.


- 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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130530/b52a9e29/attachment.html


openEHR Subversion = Github move progress

2013-05-03 Thread 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 thomas.beale at 
oceaninformatics.commailto: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 
repositorieshttps://github.com/openEHR.

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

- thomas beale


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





__ 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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130503/250bf9d7/attachment.html


translating the openEHR website [From Gunnar Klein]

2012-12-30 Thread 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.eshttp://www.openehr.org.es/, openEHR.jphttp://www.openehr.jp/ 
and openEHR.org.nzhttp://www.openehr.org.nz/ etc.) when we have the Program 
going. For those of you not familiar with this initiative: here's the 
Localisation Program Webpagehttp://openehr.org/programs/localisation/ and the 
detailed TOR 
herehttp://www.openehr.org/wiki/display/oecom/Localisation+Program+Terms+of+Reference.



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.commailto:thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.orgmailto: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.orgmailto: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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121230/d32ab8d7/attachment.html


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

2012-10-07 Thread Koray Atalag
 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.nlmailto: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

2012-10-04 Thread 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: gmailto:gfrer at luna.nlerard.freriks at 
EN13606.orgmailto:erard.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 erik.sundvall at liu.semailto: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.nlmailto:gfrer at luna.nl




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


HL7 opens up

2012-09-05 Thread 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 timothywayne.cook at gmail.com:
 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

2012-07-19 Thread 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 pazospablo at hotmail.com:
 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

2012-05-29 Thread 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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120529/ac0153dd/attachment.html


Are you doing an academic project using openEHR?

2012-03-23 Thread 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 
projectshttp://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

2012-02-20 Thread 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 thomas.beale at 
oceaninformatics.commailto: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 
forumhttp://informatics.mayo.edu/CIMI/index.php/London_2011 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 
modelshttp://www.openehr.org/wiki/display/spec/openEHR+Service+Model. We on 
the other hand 

openEHR mailing lists - moving

2012-01-20 Thread 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.orgmailto:openehr-technical at 
openehr.org will become openehr-technical at 
lists.openehr.orgmailto: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.orgmailto:xxx at openehr.org = xxx at lists.openehr.orgmailto: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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120120/e27a3e26/attachment.html


pass_through attribute in ADL 1.5

2012-01-09 Thread 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...

2012-01-06 Thread 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.semailto: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 erik.sundvall at 
liu.semailto: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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120106/dd139f43/attachment.html


13606 revisited - list proposal

2011-12-16 Thread 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?nezisabel at trajano.us.es  
 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 Arikanserefarikan at kurumsalteknoloji.com

 Hi Tom,
 Yes, such a list would be good.

 Regards
 Seref



 On Thu, Dec 15, 2011 at 12:49 AM, Thomas Beale
 thomas.beale at oceaninformatics.com  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...

2011-12-12 Thread 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.semailto:erik.sundv...@liu.se
To: openehr-technical at openehr.orgmailto: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.semailto:erik.sundvall at liu.se 
http://www.imt.liu.se/~erisu/  Tel: +46-13-286733


___ openEHR-technical mailing list 
openEHR-technical at openehr.orgmailto: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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111212/19cec613/attachment.html


Could YAML replace dADL as human readable AOM serialization format?

2011-12-08 Thread 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 k.atalag at 
auckland.ac.nzmailto: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 serefarikan at 
kurumsalteknoloji.commailto: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 they are part of 
our current

Could YAML replace dADL as human readable AOM serialization format?

2011-12-06 Thread 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111206/40e2c36b/attachment.html


CCR model

2011-07-11 Thread Koray Atalag
Hi All, I need CCR model ASAP. has anyone worked on this. Possible to share?



Cheers,
-koray




FW: [openhealth] OpenGALEN and OpenEHR

2011-07-03 Thread 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 sendermailto:fred.trotter at 
gmail.com?subject=Re%3A%20OpenGALEN%20and%20OpenEHR | Reply to 
groupmailto:openhealth at 
yahoogroups.com?subject=Re%3A%20OpenGALEN%20and%20OpenEHR | Reply via web 
posthttp://groups.yahoo.com/group/openhealth/post;_ylc=X3oDMTJxOGgwZ2xrBF9TAzk3MzU5NzE0BGdycElkAzE1MTIxMzE4BGdycHNwSWQDMTcwNzI4MTk0MgRtc2dJZAMyNjgwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTMwOTY3MTY4Ng--?act=replymessageNum=2680
 | Start a New 
Topichttp://groups.yahoo.com/group/openhealth/post;_ylc=X3oDMTJmOXE3b2ZsBF9TAzk3MzU5NzE0BGdycElkAzE1MTIxMzE4BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzMDk2NzE2ODY-

Messages in this 
topichttp://groups.yahoo.com/group/openhealth/message/2680;_ylc=X3oDMTM1YmVrdXN1BF9TAzk3MzU5NzE0BGdycElkAzE1MTIxMzE4BGdycHNwSWQDMTcwNzI4MTk0MgRtc2dJZAMyNjgwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTMwOTY3MTY4NgR0cGNJZAMyNjgw
 (1)

Recent Activity:

Visit Your 
Grouphttp://groups.yahoo.com/group/openhealth;_ylc=X3oDMTJmc3VkNmwzBF9TAzk3MzU5NzE0BGdycElkAzE1MTIxMzE4BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzMDk2NzE2ODY-

MARKETPLACE

Stay on top of your group activity without leaving the page you're on - Get the 
Yahoo! Toolbar 
now.http://global.ard.yahoo.com/SIG=15oj7g9ts/M=493064.14543979.14365478.13298430/D=groups/S=1707281942:MKP1/Y=YAHOO/EXP=1309678887/L=189cc828-a537-11e0-b450-d3b54054875e/B=.pA3GUwNO68-/J=1309671687633177/K=N23Cegzn0VPi0TotQdg0fQ/A=6060255/R=0/SIG=1194m4keh/*http:/us.toolbar.yahoo.com/?.cpdl=grpj

 
http://us.bc.yahoo.com/b?P=189cc828-a537-11e0-b450-d3b54054875eT=1d5u5qu91%2fX%3d1309671687%2fE%3d1707281942%2fR%3dgroups%2fK%3d5%2fV%3d2.1%2fW%3dH%2fY%3dYAHOO%2fF%3d1419585794%2fH%3dY29udGVudD0iR287UG9kY2FzdHM7V2lkZ2V0cztGbGlja3I7WWFob29fU2VhcmNoX01hcmtldGluZztGaW5hbmNlO0Jvb2ttYXJrO01lc3NhZ2VfQm9hcmRzO0NhbGVuZGFyO0V2ZW50czsiIGRpc2FibGVzaHVmZmxpbmc9IjEiIHNlcnZlSWQ9IjE4OWNjODI4LWE1MzctMTFlMC1iNDUwLWQzYjU0MDU0ODc1ZSIgc2l0ZUlkPSI0NDUyNTUxIiB0U3RtcD0iMTMwOTY3MTY4NzU4MzAwOCIg%2fQ%3d-1%2fS%3d1%2fJ%3d3F5EC442U=13cjg2lld%2fN%3d.pA3GUwNO68-%2fC%3d493064.14543979.14365478.13298430%2fD%3dMKP1%2fB%3d6060255%2fV%3d1

Yahoo! 

Unable to express an unit of measurements in UCUM syntax

2011-05-26 Thread 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




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

2011-05-19 Thread 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110519/5f433078/attachment.html


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

2011-05-19 Thread 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


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

2011-03-29 Thread 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


Sample OpenEHR records

2011-03-03 Thread 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 jesus.bisbal at upf.edu

 I second that. Very interested.
 I posted a similar request to this list a couple of years ago. It proved 
 difficult.
 Indeed, having such sample data is essential for testing, learning the 
 models, etc

 All the best.

 Jes?s

 On 01/03/2011 1:11, Diego Bosc? wrote:

 I would be also interested in this.

 2011/3/1 Tiago Pedrosa pedrosa at ipb.pt:

 Hi everyone,
 ? ? ? ?I'm looking for sampling OpenEHR records data. I will like to feed my
 repository with some sample data to make some test and try new
 services, does anyone knows where can I get that ?
 ? ? ? ?Thank you for your time, best regards,

 Tiago Pedrosa

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

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

 --

 

 Jes?s Bisbal-Riera ??? 
 http://www.dtic.upf.edu/~jbisbal
 Center for Computational Imaging  Simulation Technologies in Biomedicine 
 (CISTIB)
 Information  Communications Technologies Department
 Universitat Pompeu Fabra http://www.upf.edu
 c/ Tanger, 122-140 Work Ph: +34 93 542 29 51 / 25 00
 08018 Barcelona, Spain Fax: +34 93 542 25 17
 and
 Networking Biomedical Research Center on Bioengineering, Biomaterials
 and Nanomedicine (CIBER-BBN)
 Barcelona, Spain
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


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




Representing binary values with DV_BOOLEAN

2011-02-02 Thread 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 Xsome separatorRest 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 k.atalag at auckland.ac.nz:
 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




GUI-directives/hints again (Was: Developing usable GUIs)

2010-12-16 Thread 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 thomas.beale at 
oceaninformatics.commailto: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.orgmailto:openEHR-clinical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org

GUI-directives/hints again (Was: Developing usable GUIs)

2010-12-15 Thread 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
 
 http://www.ncbi.nlm.nih.gov/pubmed/17911890?ordinalpos=1itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSum
 about sharing not only archetypes but also GUI artefacts. Helma
 later extended this idea in a chapter of her thesis and
 (re)published http://www.ncbi.nlm.nih.gov/pubmed/19368989 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
 http://openehr.org/wiki/display/dev/openEHR+Composition+XML+to+HTML 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)

2010-12-14 Thread 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 
paperhttp://www.ncbi.nlm.nih.gov/pubmed/17911890?ordinalpos=1itool=EntrezSystem2.PEntrez.Pubmed.Pubmed_ResultsPanel.Pubmed_RVDocSum
 about sharing not only archetypes but also GUI artefacts. Helma later extended 
this idea in a chapter of her thesis and 
(re)publishedhttp://www.ncbi.nlm.nih.gov/pubmed/19368989 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 
mechanismhttp://openehr.org/wiki/display/dev/openEHR+Composition+XML+to+HTML 
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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101214/ac01db6d/attachment.html


GUI-directives/hints again (Was: Developing usable GUIs)

2010-12-10 Thread 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101210/d59a3c51/attachment.html


GUI-directives/hints again (Was: Developing usable GUIs)

2010-12-02 Thread 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101202/d9a7e147/attachment.html


More on ISO 21090 complexity

2010-11-22 Thread 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 way of 

What does Add reference in Archetype Editor means

2010-07-06 Thread 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100706/5889e3bd/attachment.html


Governance of terminology lists

2010-05-25 Thread 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.commailto:ian.mcnicoll at 
oceaninformatics.com
ian at mcmi.co.ukmailto:ian at mcmi.co.uk

Clinical Analyst  Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.orghttp://www.phcsg.org / 
BCS Health Scotland
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100524/ac4a7fdd/attachment.html


Medinfo 2010 openEHR tutorial collision

2010-05-17 Thread 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 
requirementsmodellingdesigndevelopment. 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 comes to mind 

Setting up a common publication/resource library for openEHR

2010-02-16 Thread 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.commailto:ian.mcnicoll at 
oceaninformatics.com
ian at mcmi.co.ukmailto:ian at mcmi.co.uk

Clinical Analyst  Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.orghttp://www.phcsg.org / 
BCS Health Scotland


On 15 February 2010 08:08, Sebastian Garde sebastian.garde at 
oceaninformatics.commailto: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.orghttp://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.orgmailto: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

2010-02-15 Thread 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.orghttp://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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100215/97cbf2b1/attachment.html


Fw: Interoperability with HL7

2010-02-11 Thread 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100211/4ce215b3/attachment.html


openEHR community on Google Wave

2009-12-03 Thread 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
 heather.leslie at oceaninformatics.com 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

2009-12-01 Thread 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

2009-11-29 Thread 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.ukmailto: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.orgmailto: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.orgmailto:openEHR-technical at openehr.org

http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical








___
openEHR-technical mailing list
openEHR-technical at openehr.orgmailto: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 Informaticshttp://www.oceaninformatics.com/

Chair Architectural Review Board, openEHR Foundationhttp://www.openehr.org/
Honorary Research Fellow, University College Londonhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCS, British Computer 
Societyhttp://www.bcs.org.uk/
Health IT bloghttp://www.wolandscat.net/






CKM Icons

2009-10-22 Thread 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091022/d76b5c49/attachment.html


Documentation Desparation

2009-09-28 Thread 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: 
 snippet of Data Types IM inserted. 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 koray at cs.auckland.ac.nz 
 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
 thomas.beale at oceaninformatics.com
 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) 
 the
 PDF and Framemaker formats.  I'll happily accept .doc files at this
 point.

 It seems that we have a different perspective on what the sense of 
 trust
 in the community is also.  But that is an entirely other subject.  
 :-)

 --Tim


 On Fri, 2009-09-25 at 11:08 +0100, Seref Arikan wrote:
   
 Dear all, 
 I'd like to express my concerns about practical outcomes of 
 suggested
 changes, changes based on potential benefits. I'd appreciate your
 input about the use cases we are discussing just to make sure that 
 I

Documentation Desparation

2009-09-26 Thread Koray Atalag
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 S,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 
 thomas.beale at oceaninformatics.com 
 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) the
 PDF and Framemaker formats.  I'll happily accept .doc files at this
 point.

 It seems that we have a different perspective on what the sense of trust
 in the community is also.  But that is an entirely other subject.  :-)

 --Tim


 On Fri, 2009-09-25 at 11:08 +0100, Seref Arikan wrote:
   
 Dear all, 
 I'd like to express my concerns about practical outcomes of suggested
 changes, changes based on potential benefits. I'd appreciate your
 input about the use cases we are discussing just to make sure that I
 get this right. 
 First of all, translation of openEHR documentation to other languages
 is a very critical task, which would be quite a challenge, because we
 are talking about very high quality documentation, to which I keep
 going back quite often, mostly to find out that a point that I was
 missing has already been there, expressed carefully. At one point I've
 thought about translating the docs to Turkish, my mother tongue, and
 realized that not having a Framemaker licence was the least of my
 problems. Reflecting the same quality, and more important than that,
 the same semantics consistenty in other languages is a huge challange.
 It requires understanding of the domain, the standard, and possesion
 of more than ordinary control over two languages, one being English.
 Also, as a member of openEHR community I would not like to see
 translations of the specs in the wild, with no official approval or
 inclusion from openEHR foundation, since this can easily lead to
 confusing documentation on an already confusing topic, which is
 challanging enough to master with really good docs. 
 I would like to know if there are efforts, or even intentions of
 translating this documentation to other languages, and the owners of
 these intentions. How many translations of the documentation will be
 for Spanish for example? If a person would give this task a try, due
 to reasons expressed above, he/she would have to possess quite a lot
 of time, skills  and he/she would have to communicate with openEHR to
 make sure that the outcomes do not do harm instead of doing good. My
 opinion is, this would be an effort linked to an institutuion like a
 university, or a government agency, working with openEHR. I can't see
 people working in their homes/offices on their own, doing this whole
 work, and if there are people like this, I really want to know them.
 The point? Well, the translation would mostly likely be performed by
 

More expressivity needed

2009-07-28 Thread Koray Atalag
Hi Tom, thanks for the comments. I see your point (and others' who 
mailed me directly).

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

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

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

The thing I have in mind is like this:

 ontology
 term_definitions = 
 [en] = 
 items = 
 [at0001] = 
 text = Term A
 description = Term
 
 [at0002] = 
 text = Term B
 description = Term
 
 [at0011] = 
 text = Term 1
 description = Related term
 
 [at0012] = 
 text = Term 2
 description = Related term
 
 relationship_definitions = 
   [is_part_of] = 
  items = 
 [at0011] = at0001
 [at0012] = at0001
 [at0012] = at0002
 
   
   [another relationship] = 
  items = 
 [at] = at


Hope I am not pushing too far ;) Any feedback from implementers?

Cheers,

-koray



Thomas Beale wrote:
 Koray Atalag wrote:
 Hi All,

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

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

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

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

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

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


 And here is a worse version of the use-case: _a given set of 
 modifiers_ apply to certain - _not all sites_ for a given organ. For 
 example the modifiers anterior wall, posterior wall applies to 
 fundus and body sites

More expressivity needed

2009-07-22 Thread Koray Atalag
Hi All,

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

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

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

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

Finally here is the nightmare version: _a different set of modifiers_ 
apply to _different _and _not all sites_ for a given organ. For example 
the modifiers Lower third, Middle third applies to Main duct site 
of pancreas and the modifiers Left intrahepatic branches, Right 
intrahepatic branches apply to Liver ducts of pancreas.

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

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

Cheers,

-koray


-- 

Koray Atalag, MD, Ph.D

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

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




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

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090722/63a8da04/attachment.html


[Fwd: [JIRA] Created: (SPEC-302) Translations embedded in the ADL are not efficient and should instead use 'gettext' catalogs.]

2009-04-29 Thread Koray Atalag
Hi Tim, an important issue for me too!

The archetypes I am working with (Endoscopy ones) are already quite big 
and there are 11 (yes eleven) languages! I completely translated one of 
them (MST Colon) and it is 6359 lines long. I also had quite an 
experience with localisation of software in past where strategies 
similar to gettext was quite practical and successful.

BUT: I think all aspects of the knowledge - including the translations 
should better stay within the Archetypes. Because:
1) If the purpose if for 'resuse', then having multiple files around can 
be quite problematic.
2) same with specialisations - have to maintain a  complex versioning 
process
3) For non-English primary language archetypes, this will make it 
impossible for others (well 99% of the rest of the World I guess) to 
understand without using tools (i.e. a text editor).

However, with the current scheme we must also decide how to modify 
translations. I don't know if this has been discussed before but 
translation changes are frequently needed and as I can see this does not 
necessitate specialisation. Perhaps with versioning of archetypes - but 
then this might create many versions out there and can make things 
complicated. In this case your proposal seems more appropriate.

One straightforward solution might be to adopt a propriety file type for 
representing archetypes - i.e. a multipart file. Still human readable 
but can accomodate more than a single file and perhaps support other 
file types as wellHowever I fear this is how usually things get very 
complicated and result in the increase of the ciriticism that openEHR is 
too complex and technical!

So as  result, I am inclined towards keeping it all in archetypes - 
unless we find a sound and sensible approach ;)

-koray


-- 

Koray Atalag, MD, Ph.D

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

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




Tim Cook wrote:
 Hi All,

 I raised the below CR and I wanted to open up discussion on this issue.
 Actually I brought it up a few years ago but I don't have a record of
 where/when; now.

 I know that this have a major impact on implementers but I think the
 current way we handle translations in ADL is a monster that is only
 going to get worse.

 Thoughts?

 --Tim


  Forwarded Message 
 From: Tim Cook (JIRA) jira-admin at openehr.org
 To: timothywayne.cook at gmail.com
 Subject: [JIRA] Created: (SPEC-302) Translations embedded in the ADL are
 not efficient and should instead use 'gettext' catalogs.
 Date: Tue, 28 Apr 2009 21:47:02 +0100 (BST)

 Translations embedded in the ADL are not efficient and should instead use 
 'gettext' catalogs. 
 --

  Key: SPEC-302
  URL: http://www.openehr.org/issues/browse/SPEC-302
  Project: Specification
   Issue Type: Change Request
 Reporter: Tim Cook


 Archetypes like openEHR-EHR-OBSERVATION.blood_pressure.v1 with four 
 translations are huge and tedious to process the languages. 
 openEHR should adopt the standard use internationalization (i18n) and 
 localization (i10n) tools that use gettext catalogs.  This is the industry 
 standard approach to performing translations. Tools like POEdit are open 
 source and cross platform http://www.poedit.net/ 

 More info about gettext is here: 
 http://www.gnu.org/software/gettext/manual/gettext.html though it is about 
 the GNU set of tools there are others.  

 What will openEHR-EHR-OBSERVATION.blood_pressure.v1 look like with 10, 15, 
 100 translations?


   
 

 ___
 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/20090429/149464e7/attachment.html


Implicit semantics within Archetypes?

2009-02-19 Thread Koray Atalag
Hi,

I think ADL has proved to be a pretty good knowledge modelling language 
and that the growing number of archetypes represents a good deal of 
clinical knowledge. What is lacking is the ability to define 
relationships and their types between nodes or even nodes in other 
archetypes. I don't really know if this is possible via invariants - but 
I think this should be pretty easy with the introduction of a few 
keywords and definitely would not imply any changes in the RM (I hope).

There are a number of situations where I think this might be useful:
1) openEHR is criticised in 'other' rounds for the lack of computable 
semantics inside the Archetypes and Templates and that they say 
delegating all the semantics to terminology via bindings is not a safe 
and sound approach. Although I am fully aware of the power of openEHR 
with regard to semantic coherence, I think there is nothing wrong to 
define  some basic semantics inside the archetype. That is actually part 
of the domain knowledge.
 
2) It is possible to build a 'real' domain ontology - say mini-ontology 
without depending on other formalisms. Some of you might say what is the 
point of building a domain ontology with ADL...Well I can think of 
better validation during data entry, processing, GUI design, querying 
etc.-nearly all aspects.

3) It is one of our strongest arguments that Archetype do not need an 
external terminology - can rely on its own local codes. External 
terminology just adds more semantics into. So far so good - But what 
happens to a mission critical DSS application when terminology server 
goes down? Or, in most cases, a terminology for that concept does not 
exist at all? Or exists but in another language?

The formalism is already there - 95% of work has already been done to 
make ADL a great knowledge representation language. So why not do the 5%?
BTW I am by no means a knowledge management expert, but had some 
experience with other formalisms (especially Protege) for clinical 
modelling.

Cheers,

-koray






Formal methods for Evaluation of Interoperability Maintainability?

2008-02-12 Thread Koray Atalag
Hi Gerard,

I am talking about metrics like the one you had suggested previously: # 
of interfaces to be implemented to achieve interoperability with no 
message standard, some message standard and two-level systems. It is 
clear and easily computable and very objective. Perhaps it is worth 
studying qualitative part of the story too apart from just # of interfaces.

Sam also suggested the possibility of assessing archetype reuse (I don't 
know how to measure that though)

And Rong has suggested to explore how EHR systems work together with 
other EHR and surrounding systems - that is hard to assess but I think 
the only way to test it.

In Sam and Rong's case we need some metrics which is applicable to both 
single level and two level apps and then measure accordingly. Now after 
quite a literature search and reading, considering both maintainability 
and interoperability are software quality characteristics there is vast 
amount of material out there; mainly under Software Product Quality 
Measures or specific on those attributes. Here is an example on 
maintainability:

? Fix backlog and backlog management index

? Fix response time and fix responsiveness

? Percent delinquent fixes

Fix quality

* backlog management index (BMI)=

I think an archetype based two-level app will beat with this index

* Fix Response Time and Fix Responsiveness: this will be the killer 
metric I assume.

Reference: Software Quality Metrics Overview, Book Chapter (4)  By 
Stephen H. Kan., Dec 20, 2002

There are many many more of those; and I think we need to identify 
relevant ones, especially the metrics which forecast on the quality of 
product based on design, before actual implementation.

Sorry to bother with all this on discussion list and if there is more 
interest we can continue on the wiki.

-koray


Gerard Freriks wrote:
 Koray,

 What metrics do you want to define?

 Gerard


 On Feb 11, 2008, at 10:40 AM, Koray Atalag wrote:

 Dear All,

 I started this thread to get some feedback for finding methods/metrics 
 to test  validate maintainability and interoperability (of Archetype 
 based two-level apps). And I got very nice ones; however for 
 interoperability, apart from Gerard's interface numbers I did not get 
 any and interestingly from a quick literature survey I got very little. 
 I mean there are some indirect approaches but not straightforward. My 
 case is a little more easier:

 1) There is an up and running clinical IS developed with single level 
 methodology based on an internationally agreed terminology including 
 relationships and structure (domain knowledge let's say)
 2) There is a complete Archetype model of this terminology using openEHR 
 RM which can comfortably be considered as a domain ontology (it has more 
 than what is given in terminology; i.e. existences, cardinalities)
 3) These two can be said to have the same domain knowledge; ie. one 
 hardcoded and one two-level modelled.

 Now can you think about a method to evaluate the interoperability 
 levels/score of two systems?

 Do we need a remote system for benchmarking (i.e. connect and see how 
 they interoperate)?

 Sorry to botherbut if we can get this straight perhaps we can 
 express comfortably that a two-level app beats a single level app 7x in 
 maintainability and 5x interoperability. Or beats 2x HL7 system in 
 maintenance but is beaten 2x in interoperablity.  Perhaps I am being too 
 naive but it is worth trying.



 -- private --
 Gerard Freriks, MD
 Huigsloterdijk 378
 2158 LR Buitenkaag
 The Netherlands

 T: +31 252544896
 M: +31 620347088
 E: gfrer at luna.nl mailto:gfrer at luna.nl


 Those who would give up essential Liberty, to purchase a little temporary 
 Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755





 

 ___
 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/20080212/90c34890/attachment.html


Formal methods for Evaluation of Interoperability Maintainability?

2008-02-11 Thread Koray Atalag
Dear All,

I started this thread to get some feedback for finding methods/metrics 
to test  validate maintainability and interoperability (of Archetype 
based two-level apps). And I got very nice ones; however for 
interoperability, apart from Gerard's interface numbers I did not get 
any and interestingly from a quick literature survey I got very little. 
I mean there are some indirect approaches but not straightforward. My 
case is a little more easier:

1) There is an up and running clinical IS developed with single level 
methodology based on an internationally agreed terminology including 
relationships and structure (domain knowledge let's say)
2) There is a complete Archetype model of this terminology using openEHR 
RM which can comfortably be considered as a domain ontology (it has more 
than what is given in terminology; i.e. existences, cardinalities)
3) These two can be said to have the same domain knowledge; ie. one 
hardcoded and one two-level modelled.

Now can you think about a method to evaluate the interoperability 
levels/score of two systems?

Do we need a remote system for benchmarking (i.e. connect and see how 
they interoperate)?

Sorry to botherbut if we can get this straight perhaps we can 
express comfortably that a two-level app beats a single level app 7x in 
maintainability and 5x interoperability. Or beats 2x HL7 system in 
maintenance but is beaten 2x in interoperablity.  Perhaps I am being too 
naive but it is worth trying.

Koray Atalag wrote:
 Hi,

 I want to learn how we can formally/objectively prove that Archetype 
 based dual level development formalism alleviates problems of 
 interoperability and maintainability. I was wondering if someone did or 
 know of any such study which applies formal validation methods?

 Best regards,

 Koray Atalag, MD, Ph.D.

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

   



Formal methods for Evaluation of Interoperability Maintainability?

2008-02-11 Thread Koray Atalag
Hi Juanita, I would be honoured indeed :)

Just a small remark I want to share with you all: After working in the 
field of clinical information systems (My own firm in Turkey established 
in 1996) I faced with the many problems we discuss here from firsthand 
and said enough, sold my shares and got back to academia. In all the 
projects and tenders we got, we in fact lost money due to changing 
requirements and a general lack of understanding in procurers and laws. 
I evaluated openSDE, Protege and some other propriety tools but then 
discovered openEHR in 2001 or beginning of 2002. I also did a very risky 
thing and based my Ph.D. research on this! Well, it took 7 years for me 
to finish it (!) I am happy now that I chose it and very anxious to 
conduct some quality research.

Friendly regards,

-koray

Juanita Fernando wrote:
 Hiya Koray,

 It sounds like we may be able to collaborate in the future, which is 
 fabulous. I'll be in touch

 Cheers

 Juanita

 Koray Atalag wrote:
   
 Hi Juanita and others,

 It would be a great research topic and I think one that is needed very 
 badly from openEHR community. If I manage to find an appropriate 
 research position, this would definitely fall within scope of my 
 research as I already have necessary experience and data in endoscopy as 
 explained in my thesis.  I have been  investigating this subject because 
 of a paper in progress which summarizes my thesis work and I want to 
 inform readers about other studies which claim Archetype bases two-level 
 modelling is superior to classical one in terms of maintainability, 
 interoperability and domain knowledge governance; preferably with 
 objective formal methods. Of course it is hard considering that this is 
 a new paradigm and tricky due to the nature of problem. What I saw is 
 this: formal methods are negligibly scarce and current data is mostly 
 coming from expert opinion. There is a very interesting whitepaper 
 (2004) which explains why single level modelling fails in development 
 and maintenance. It is not really very scientific(?) but you may find it 
 useful anyways:

 A Practical Implementation of a Two Level Archetype Based Clinical Model
 http://www.meridianhi.com/IDME_Whitepaper.htm

 One last thing about HL7: I read that paper by Ceusters  Smith; it is 
 interesting though but there is another paper as response from HL7 
 rounds and both seem to tell about facts from different perspectives. I 
 feel that HL7 is over-criticized here and that this would not increase 
 the value of this work for sure. I used v2.4 messages myself and I found 
 it very useful like many. Simply their move with v3 to become a content 
 standard apart from messaging which is then extended to be an EHR 
 standard is not an elegant approach.  Maybe we all criticize about this 
 aspect, but then it results in a general dislike about whole HL7. And 
 keep in mind that only time will show who will survive; think about 
 (annoying) existence of cockroaches appearing many million years before 
 elegant species in biologic evolution :D

 Best regards,

 -koray

 Juanita Fernando wrote:
   
 
 Hiya,
 I'm thinking of doing some post doc work in this area later on this 
 year. I thought you might find this reference useful too Koray:

 Smith B, Ceusters W. HL7 RIM: An incoherent standard. Studies in Health 
 Technology and Informatics. 2006 August 2006(124):133-8.

 Cheers

 Juanita

 ___
 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

   



Formal methods for Evaluation of Interoperability Maintainability?

2008-02-07 Thread Koray Atalag
Hi Gerard, a very useful document indeed...The approach is quite 
interesting and solid; no questions mathematically (at least in my MD 
mind!). I was thinking about brainstorming about finding some metrics 
(logical and feasible to experiment) to test those issues. Such as:

Maintenance: comparison of lines of code during maintenance, frequency 
of support requests and time to fulfill them, user satisfaction surveys, 
cost figures and so on for maintenance

Interop: your points (i.e. # of interfaces to be implemented, # of 
messages and schemas), number of transactions, reused fragments, number 
of hops during a shared care event (i.e. how many systems particular 
data (EHR extract?) travels, how many users access it and how.

These are just initial thoughts and I am sure there are already better 
ones out there. I think, seriously, such studies would be very 
beneficial for community in convincing interested parties.

-koray


Gerard Freriks wrote:
 HI,

 Via the Url a PDF/presentation with some calculations.
 No message standard, any message standard and the two-level-model 
 paradigm, are compared.
 http://tinyurl.com/26hlch

 Gerard



 On Feb 6, 2008, at 9:28 PM, Sam Heard wrote:

 Hi Koray

 I think we will have to come up with some metrics that are relevant 
 as it has not been done before in the domain space. Clearly modelling 
 at two levels is a common approach - relational databases model the 
 idea of tables with rows and columns, linking keys, data types and 
 indexes. The domain information is expressed in terms of these rows 
 and columns. Many systems driven on metadata do the same thing. What 
 is new about openEHR is a generic approach to allow any  base model 
 to be constrained through the use of ADL. The result is that the base 
 model can reflect the general business rules and the  fixed 
 information constructs - the archetypes the domain knowledge and how 
 it is represented in terms of the base model. The approach relies 
 only on getting sufficient expressivity at the base level to make the 
 split efficient and safe.

 The comparison in health care at present is with HL7 version 3. This 
 has a base model (RIM) from which a new model, an RMIM, is 
 constructed (level 2). The difference is that RMIMs are constructed 
 with alterations to the RIM classes (which are renamed). So we now 
 have a new class based on a pattern. The semantics of the RMIM is a 
 mixture of RIM and RMIM and difficult to untangle. CDA is using 
 templates in the same way as openEHR uses archetypes - to express 
 some domain content. As CDA is already committed to XML, the means of 
 further constraint is limited - hence the use of schematron and other 
 devices.

 I guess the first metric that we could consider is the speed at which 
 domain concepts can be modelled and the level of human intervention 
 for documentation and maintenance. The UK NHS, which has the most 
 experience of both, has found openEHR far more efficient to use than 
 MIF template constraints on HL7 CDA. Vendors are cautious and have 
 little experience of openEHR directly as yet.

 Clearly archetypes are of great use in systems that use the openEHR 
 Framework and allow use of operability constraints out of the box. 
 What about other vendor systems? Well, Ocean tools are being used to 
 produce inputs for vendors which are formal specifications of data to 
 be stored and communicated. The ability to reuse these artefacts for 
 many purposes - queries, transformations, display and data entry 
 provides another metric that is of use.

 We will need some large systems built on openEHR and traditional 
 approaches to compare in the future. For the moment, just having 
 clinical specifications that are computable is the main influence on 
 choosing openEHR - or starting from scratch as new vendors see the 
 benefits (or not).

 Cheers, Sam

  

 Koray Atalag wrote:
 Hi,

 I want to learn how we can formally/objectively prove that Archetype 
 based dual level development formalism alleviates problems of 
 interoperability and maintainability. I was wondering if someone did or 
 know of any such study which applies formal validation methods?

 Best regards,

 Koray Atalag, MD, Ph.D.

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


   

 -- 
 OceanC_small.png   Dr Sam Heard
 Chief Executive Officer
 Ocean Informatics

 Director, openEHR Foundation
 Senior Visiting Research Fellow, University College London
 Aus: +61 4 1783 8808
 UK: +44 77 9871 0980
 ___
 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



 -- private --
 Gerard Freriks, MD
 Huigsloterdijk 378
 2158 LR Buitenkaag
 The Netherlands

 T: +31 252544896
 M: +31 620347088
 E

Formal methods for Evaluation of Interoperability Maintainability?

2008-02-06 Thread Koray Atalag
Hi,

I want to learn how we can formally/objectively prove that Archetype 
based dual level development formalism alleviates problems of 
interoperability and maintainability. I was wondering if someone did or 
know of any such study which applies formal validation methods?

Best regards,

Koray Atalag, MD, Ph.D.




Congraturation to our new Web site

2007-11-03 Thread Koray Atalag
Hi,

I also want to put some words here...For too long, compared to the 
quality of the work done here, openEHR Website was just lagging a lot 
behind...During many times when I gave some presentation or in meetings 
with interested people and showed openEHR Website, I visualized some 
expressions of disappointment in their faces. But nowIt is all 
changed and for the very better :) Thanks to people who put a lot of 
effort in it.

Just one small notice, when you go to wiki by the link from homepage, 
there is no return back (except back button). Might be nice to have a 
direct link to openEHR homepage in wiki.

-koray

KOBAYASHI, Shinji wrote:
 Now, we can access our new web site. It is very smart and cool.
 Though, it seems to me that took some difficulty and troubles, the web
 team has successfully finished to establish this site.
 I praise and appliciate this great work on web team. Thank you!
 And please take care of yourself.

   



Further value constraints: in Archetypes or Templates?

2007-10-30 Thread Koray Atalag
Dear All,

I have an important modeling problem in ADL for defining whether single 
or multiple selection is allowed for values of an ELEMENT. In (very 
informal) other words checkbox or option box. During a recent discussion 
with Thomas, I learned that this has previously been discussed and that 
current trend is to move this into templates together with the 
constraint about default values.

I can perfectly understand and appreciate to define default values in 
templates as they can be dependent on regional, cultural or even 
religious matters. But considering the principles expressed 
(wonderfully) in a previous thread about archetypes and templates, one 
can simply come to a conclusion that (almost) universal and non-volatile 
domain knowledge go into former while local/volatile knowledge go into 
latter. In any concept such constraints are an integral part of that 
domain knowledge; i.e. an ELEMENT defining presence of bleeding can not 
have both present and absent. Of course then there might be other cases 
where this can not be determined in advance- so you simply do not 
constrain them in archetypes and handle with local templates.

The rationale behind my similar requests/suggestions is very simple: I 
prefer to be able to model concepts and implement them without depending 
on templates; just archetypes and that's all. I know that this is not 
the mainstream approach/business model but it can improve stability of 
archetypes and add flexibility in openEHR/CEN implementations.


Best regards,

Koray Atalag, MD, Ph.D.



Multiple parents and max number of nested specialized archetypes?

2007-10-16 Thread Koray Atalag
Hi,

I have a question about the referencing of archetypes in specialization. And 
also want to know if there is a limit on the number of specializations of 
archetypes.

For example:

A is top level archetype
B is specialization of A
C has to further specialize B
and there is possibility that D also has to further specialize C and so on.

So in theory all childs have to conform to A. But the question is in C which 
archetype will be written in 'specialize' section? A or A  B ? I assume it is 
currently B. But in theory, possible one in a million, a particular specialized 
archetype might conform to multiple parents...In my opinion this is perfectly 
possible. So what happens?

The other question is whether ADL or other limits the number of specializations.

Best regards,

Koray Atalag, MD, Ph.D.

Freelance consultant and developer
http://koray.pathos-web.org
skype: atalagk


  

Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel 
and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 





Value or Null_Flavor in CLUSTERs?

2007-02-13 Thread Koray Atalag
Hi Sam,

Thanks for your (always) kind answer...My comments  reply is below

Sam Heard wrote:
 Hi Kory

 You can have an empty clusterif you want to say why it is empty 
 then use null flavor on one or more of the possible elements.
Yes this is exactly what can be done now...But when starting to think 
(or even implement) archetypes not merely as abstract clinical concept 
models but as objects or program data (as instances) then this may issue 
become more obvious.

 If these do not suffice as approaches I probably need the precise 
 example. It suggests that your model may not be optimal.

 Cheers, Sam
Well you are definitely right (and polite) about my models...I also 
suspect that they are might not only be optimal but I am trying. The 
previous example was meant to be the precise example but I assume did 
not make sense (even to me now!). Well instead of an example I will 
shortly summarize the issue by example:

Consider instances of some archetype; let's say with 2,3 levels of 
nested Clusters each having many elements in leaf nodes. The archetype 
may describe a cardiovascular patient history and these particular 
clusters happen to define Risk factors. So one path might be:  Risk 
factors  Smoking  Cigarette  Quantity. And if a patient has no risk 
factors, all the entries will be null in runtime instance and eventually 
in the database.

Think about the simplicity of putting a flag or null_flavor at the top 
node so that a query or a GUI generator will utilize for better 
performance. Is there any other way than checking each path for element 
value/null_flavor path? And think about this for millions of records.

What disturbs me most with as is approach is that the control is 
transferred to implementors in deciding to either put an element under 
each cluster or depict presence/null_flavor on clusters.

Thanks for your patience...

-koray

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





Value or Null_Flavor in CLUSTERs?

2007-02-03 Thread Koray Atalag
Hi,

I know that this is probably something very inappropriate but I happened 
to need such a solution. An example:

CLUSTER []
CLUSTER []   Some type of finding (a lesion: ulcers)
  ELEMENT []   A Feature of the finding (i.e. bleeding)
v: some value
  ELEMENT []  Another Feature of the finding (area)
v: some value
ELEMENT []   Another type of finding   (a lesion: atrophy)
v: some value  OR null_flavor

My problem is I want to be able to state whether CLUSTER[] is 
observed (True) or not (False) when both features (ELEMENTs  and 
) are not present (NULL). I am perfectly able to state it when the 
data structure is an ELEMENT.

Problem arises when none of the features (attributes) of CLUSTER [] 
is observed and that two things can happen:
1) None of the features could really not be assessed, but there is 
definitely an ulcer (presence=TRUE)
2) The lesion in CLUSTER [] is not visualized at all 
(Presence=FALSE). But then we need to know why (classical flavors of null)?

Of course a straightforward solution is putting under each CLUSTER with 
child nodes, a new ELEMENT describing its presence with Boolean type 
and with null_flavor.

However if it will not break very badly current semantics and other 
strategies, the advantages of such approach might be:
1) Reducing size, manageability and understandability of (big) archetypes
2) During querying of leaf-nodes in a huge repository, the search 
algorithm can first check parent nodes' presence and then further go 
down to leaf-nodes. If a whole branch is not valid/null from the top, 
then there is no need to look for lower levels and the performance might 
be enhanced.

I might be making a horrible proposal here technically or even there 
exists another solution already, but this is what I need.

Best regards,

Koray Atala, M.D.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical





Problem in some sample archetypes and questions

2007-01-08 Thread Koray Atalag
Sam Heard wrote:
 Thanks Koray

 Your expression of cardinality and occurrences is exactly correct - 
 there are clearly some errors in the archetypes.

 The only reason to limit cardinality in the archetype is to force a 
 choice when there are more than one child e.g.

 container x with cardinality 1..2
 has children a (occurrences 1..1)
b (occurrences 0..1)
c (occurrences 0..1)

 This forces a choice between b and c.

 Cheers, Sam
Hi Sam,

Thanks for your kind answer and simple explanation; I just needed that 
:) Regarding the errors in the archetypes (and possibly others as well) 
I think it would be nice to have this kind of semantic/validity check 
built into ADL parser or the tools. Currently both the Editor and the 
Workbench allow these type of errors.

Also if you take a look at my previous questions 2 and 3, they are 
pointing out to some other aspects of ADL and archetype design. I would 
highly appreciate some guidance here though not urgent at the time.

Best regards,

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





Problem in some sample archetypes and questions

2007-01-08 Thread Koray Atalag
Stap, R.E. (Roel) wrote:
 Hello Koray,
  
 Reading your issues around cardinallity, perhaps you can solve this 
 issue with help of constrains/business rules. E.g. if you consider in 
 the Archetype model the ability to have a cardinality between A and B 
 of (0..N), you can constrain practically this cardinality to a maximum 
 of e.g. 4. The risk of modelling you cardinalities so precise in the 
 archetype model is that if in future this is changed, your system 
 (e.g. database schema's or applications) needs to be updated if this 
 cardinality changes. If you are able to define the reason of this 
 cardinality in rules you may create the flexibility in future to adapt 
 this without changing systems or applications. I am not sure if this 
 will help you, but consider this mechanism to handle cardinalities issues.
 I hope this may help you in finding a solution for your issue,
  
 regards
 Roel
  
  
Hi Roel,

Thanks for the information you provided; especially the one about the 
effect of archetype design on the resulting software and database 
schema. I would still like to take your attention to my specific 
questions 2 and 3. These point out to very detailed aspects of archetype 
design - ones that most probably will never encounter while designing 
their archetypes.

Best regards and Bedankt!

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





Problem in some sample archetypes and questions

2007-01-07 Thread Koray Atalag
Hi to all,

While revising my MST archetypes, I came across some confusion on the 
use of cardinality and occurences. And when I reread ADL 1.4 and ADL2, 
inspected the sample archetypes and then created new ones with Archetype 
Editor and also tested with the Workbench my confusion got even more 
increased. Here is the problem description and some questions:

As stated in ADL 1.4: Cardinalities indicate limits on the number of 
members of instances of container types such as lists and sets. From a 
simpler point of view, what I understand it tells the min and max 
allowed number of beads (same or different beads) in a box. From a more 
sensible way in the realm of clinical archetypes written in ADL, it is 
used to constrain the min and max allowed number of run-time instances 
of child nodes of attributes which can be a container such as  CLUSTER, 
ITEM_TREE, ITEM_LIST, HISTORY and so on.

So far so good but I have a practical problem to model a situation like 
the following:
PARENT_NODE (A container type and might not exist or repeat up to  2 times)
a) CHILD_NODE (Must appear once)
b) CHILD_NODE (May appear 0 to 8 times)

So this roughly can be expressed as:
CLUSTER occurences {0..2}
any container attribute cardinality {1..9}
QUANTITY occurences {1..1}
ELEMENT   occurences {0..8}

PROBLEM-1: As understood from above description that cardinality simply 
depicts the number of instances of subchilds - REGARDLESS of their type 
(i.e. QUANTITY or ELEMENT), then above cardinality can be {1..9} or 
simply {1..*}. When I examine some sample archetypes such as Line 67 in 
autopsy.v1, Line 33 in respiration.v1 and Line 103 in microbiology.v1 
the cardinality of container node is {0..1} and they have a number of 
child nodes with occurences 0 and it is clear clinically that almost 
ALL of those nodes should appear in runtime data. So there is either a 
misunderstanding of the use of cardinality here among most of us or I am 
totally lost here :)

The above model is expressed in those archetypes roughly as follows:

CLUSTER
any container attribute cardinality {0..2}
QUANTITY occurences {1..1}
ELEMENT   occurences {0..8}

QUESTION-1: What is the correct approach for above problem?

QUESTION-2: Assume in some other place in the archetype you reference 
the ELEMENT node with occurences {0..8} by use_node. And in this 
particular place you do not want to have up to 8 instances and but also 
you want it to be mandatory (i.e. 1..) or even want {3..5}. What is the 
solution? (other than writing the whole thing once again)

QUESTION-3: Related with second question, I also need to disallow usage 
of some values when referencing by use_node entries. This I believe is 
not an uncommon requirement in clinical medicine.For me I have an 
element with a long list of  values of sites of an organ (Esophagus, 
stomach, colon and so on) and in many places of an observation these 
sites repeat without change so I can reference original. But in some 
cases selection of certain site(s) is not logical and should better be 
restricted or selection of only one site makes sense. What is the solution?

Thanks and happy new year to all...

-koray



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





FW: FreeTerminology.org is UP!

2006-01-28 Thread Koray Atalag
Here is the post I had sent to openhealth forum... Will need your support

 

Best regards,

 

Dr. Koray Atalag

 

  _  

From: Koray Atalag [mailto:atal...@yahoo.com] 
Sent: Saturday, January 28, 2006 1:28 PM
To: 'openhealth at yahoogroups.com'
Subject: FW: FreeTerminology.org is UP!

 

Hi FOSS people,

 

Not always I do objections and create nebulizing clouds, but also do some
useful work ;)

 

So, in spite of the possibility/fear of ending up in a prison :-) I have
taken my individual liberty with good will to create the following project
at SF. And it was accepted lightning fast! 

 

The project is in fact in Planning Phase, but I would love to get your
comments before proceeding further...I hope to fill it with useful content
for FOSS projects, in about a month. And I also need developers to help me
to implement the simple Web interface; just cgi programming connected with
MySQL services provided from SF.net.

 

Pls. refer to Project Website for aims and specific goals of the
FreeTerminology.org project...

 

May I also announce that all my projects (5 of them now) are opt in to
receive donations and 25% yes REPEAT 25% is going to FOSS Community... I
already earn my life by consulting in a very different domain: e-Government.
So my primary concern with healtcare projects is not monetary; but to gain
more knowledge/experience...And I do it for the future of my daughter -
Karya (and many others')

 

Best regards and happy using,

 

-koray (maddoc)

 

P.S. Yeah good friends call me with the nickname maddoc...And I like it!

 

  _  

From: Koray Atalag [mailto:atal...@yahoo.com] 
Sent: Friday, January 27, 2006 9:26 PM
To: 'Sam Heard'; Thomas Beale
Subject: FreeTerminology.org is UP!

 

Hi,

 

I just wanted to announce that http://freeterminology.org/ is now up and
working...Of course I need help to fill it up.

 

I got a long list of requirements and cool ideas...

 

Sevgiler,

 

-koray

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060128/8494f823/attachment.html


difficulties starting an implementation

2006-01-19 Thread Koray Atalag
...openSDE has a
methodology called the Entity Export and openEHR proposes a term:
Intelligent Querying...

I am also putting Astrid van Ginneken and Marcel de Wilde in the CC list so
that maybe they want to speak for themselves...And also Dr. Bemmel so that
he may be interested with (and hopefully support) openEHR...

Pretty exciting ha?

Best regards,

Dr. Koray Atalag

 -Original Message-
 From: owner-openehr-technical at openehr.org [mailto:owner-openehr-
 technical at openehr.org] On Behalf Of Sebastian Garde
 Sent: 18 Ocak 2006 ?ar?amba 02:16
 To: openehr-technical at openehr.org
 Subject: RE: difficulties starting an implementation
 
 Hi Bert,
 
 the way I understand the differences between openSDE and openEHR:
 
 In comparison to openEHR, openSDE does not seem to offer a really
 clear separation between the domain model and the information model,
 it does not seem to have a information/reference model comparable to the
 one of openEHR
 or separate clinically meaningful knowledge-entities like archetypes
 offer.
 In my opinion, openSDE is optimised for structured data entry rather
 than semantic interoperability.
 While this is ok for one hospital, in my opinion it does not really
 help with semantic interoperability in the long run.
 
 That not withstanding, I believe openEHR can learn from openSDE when
 implementing the openEHR model:
 For example, openSDE offers some really good features within the GUI -
 how to
 document structured data, how to display it.
 That this can be done with a openEHR /archetype-based approach remains
 to be shown, but I am quite confident that it can be!
 Further, openSDE uses 'row modelling' (see
 http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=353023)
 to convert their domain model to a database and store data which offers
 some advantages
 (e.g. no or less changes are needed in the database when knowledge
 changes).
 But when implementing openEHR you most likely wouldn't want to use
 clinically meaningful relational database tables either,
 but rather store clinical data in accordance with the openEHR model
 (i.e. in compositions, entries, etc).
 So you could say, openEHR would then use 'advanced' row modelling.
 
 In my opinion, the patience of openEHR will be rewarded soon.
 
 Regards
 Sebastian
 
 Dr Sebastian Garde
 Faculty of Business and Informatics
 Central Queensland University
 Rockhampton Qld 4702, Australia
 
 s.garde at cqu.edu.au
 Ph +61 (0)7 4930 6542
 Fax +61 (0)7 4930 9729
 http://healthinformatics.cqu.edu.au
 
 
 -Original Message-
 From: owner-openehr-technical at openehr.org
 [mailto:owner-openehr-technical at openehr.org] On Behalf Of Bert Verhees
 Sent: Wednesday, 18 January 2006 8:46 AM
 To: openehr-technical at openehr.org
 Subject: Re: difficulties starting an implementation
 
 Hi all,
 
 Got some tips, just put a database under it and a GUI above, and there
 is an application.
 Sounds to me like a practical joke ;-)
 If it is that easy? why isn't this easy piece of work not published,
 somewhere on the openehr website?
 
 I have no problem writing a GUI, or a persistence-layer, in fact, that
 are the most simple things to do for a programmer.
 First year of the programmers school you learn using and writing
 persistence layers.
 OK, to write a good GUI involves usability-knowledge. But a stupid GUI
 any programmer can build.
 
 Is a special structure of the persistence-classes needed, an API so to
 say? I guess so, but that is only one of the questions.
 But how to connect them to the OpenEhr class-structure puzzles me. F.e.
 a few sequence diagrams with classes in it would help.
 
 I know, the idea of OpenEhr is in fact simple, beautiful by its
 simplicity. When working out, simplicity turns into complexity. A normal
 process in ICT.
 I know from experience that for someone involved in building a project,
 it is very easy to understand its documentation.
 In fact such a person does not even need the docs.
 For someone coming new to such a project it is very hard to step into
 the many many pages of documentation.
 This is espcecially true when there is nothing really doing something,
 and the project is incomplete.
 
 Something else:
 OpenSDE
 http://www2.eur.nl/fgg/mi/OpenSDE/
 I looked to the openSDE-project, which should be inspired by the
 OpenEhr, as I heard. It really takes to much of my time, to find out if,
 or in howfar this is true.
 Maybe someone want to say something in short about this.
 
 I was spending some time in their docs, and I found that it was a very
 open project. The db-scheme's are documented, the API's which are
 involved in every part of its functionality are explained in detail. I
 could start right away with this project.
 My first impression is that it is flexible in implementation, easy in
 implementation, it has a domain model editor, a simple datamodel, it
 looks a lot like OpenEhr, but I must say, I am not the right person for
 qualifying this. I hope people who are, and reading

difficulties starting an implementation

2006-01-19 Thread Koray Atalag
Dear Dr. Hammond,

We now have started a very ambitious national EHR project called Turkish
Health Information System which addresses nearly all aspects of the
domain...I am not so sure whether it will be a success but it the current
government is very serious about it and employed highly qualified
professionals. There is an English document you can examine:

Title: Review of and Recommended Improvements to Turkey eHealth Strategy
By: 

Salah Mandil, Ph.D.
Senior Expert Consultant
on eHealth  eStrategies, to the
International Telecommunications Union
and,
Former Director
Health Informatics  Telematics
World Health Organisation
Geneva, Switzerland

The pdf is at: http://www.saglik.gov.tr/eng/turkeyehealth_bu.pdf

Best regards,

Dr. Koray Atalag

 -Original Message-
 From: owner-openehr-technical at openehr.org [mailto:owner-openehr-
 technical at openehr.org] On Behalf Of William E Hammond
 Sent: 19 Ocak 2006 Per?embe 16:22
 To: openehr-technical at openehr.org
 Subject: Re: difficulties starting an implementation
 
 Ian,
 
 I am writing a paper on national mandates for HIT and on nation adoptions
 of the EHR.  Can you point me to some documentation on Scotlands plans?
 
 Thanks
 
 Ed Hammond
 
 
 
 
   Ian McNicoll MMS
   ian at gpacc.co.uk   To:   openehr-
 technical at openehr.org
   Sent by:cc:
   owner-openehr-technical@Subject:  Re:
 difficulties starting an implementation
   openehr.org
 
 
   01/18/2006 03:47 PM
   Please respond to
   openehr-technical
 
 
 
 
 
 
 Hello again Rong,
 
 Glad to hear things are progressing. Do you have any thoughts about
 persistence layer options?
 
 In Scotland there is a hope to move to a single EHR for the whole
 country across all specialities. Personally I remain unconvinced that
 this is totally achievable, but if it is, it will demand a highly
 flexible and extensible architecture, backed by an equally structured
 complex persistence layer - the traditional relational DB will simply
 not work.
 
 Regards,
 Ian
 
 
 
  As I promised to reply to your post on the list, here I am. :)
 
  Personally I am convinced it is possible to implement the openEHR
  specification even at this stage. We, at Acode, already proved it by
  building a pilot EHR system which meets real-life requirement. Of
  course, it wasn't easy since we started from scratch with the Java
  implementation (kernel, parser, persistence, GUI), but also the
  specification has been a moving target. After the version 1.0
  specification is released, the situation will be quite different. Since
  then, there won't be any major changes on the reference model which
  really is the foundation of interoperable EHRs. This will hopefully
  encourage more open source or commercial development on openEHR in the
  near future.
 
  Cheers,
 
 
 






difficulties starting an implementation

2006-01-17 Thread Koray Atalag
 (i.e. via use_achetype notation). In 
my thesis work I have to model completely the Minimal Standard Terminology for 
Endoscopic Gastroenterology which is more than a standard terminology but an 
ontology. So in order to have a useful arhetype which I can use for validating 
my data and creating dynamic GUI for SDE I need to assemble for an Upper GIS 
Examination: Esophagus, Stomach and Duodenum archetypes just to describe 
Findings...But then I also have to manage the Diagnosis, complications, 
Additional Diagnostic and Therapeutic Procedures and so onI think the 
resulting top level Findings of Upper GIS Examination Archetype should have 
features like History, Event Series, Protocol and so onBut the smaller 
components for Esopgahus, Stomach does not need to have these contextual 
attributes...So I must be able to assemble them just using a simple tree with 
Clusters and other leaf nodes. So the structural archetypes might possibly be 
without these features; the generalized top level clinical archetype can have 
them. The major problem with current approach is that if due to some problem 
with data consistency or design errors in an HIS, there may start some 
esopgahus data flying around without other proper related components. 

Of course there are the templates...But I do not have any idea how it will 
solve this problem...Maybe we can start another discussion on the Templates 
approach.

Best regards,

Dr. Koray Atalag



 -Original Message-
 From: owner-openehr-technical at openehr.org [mailto:owner-openehr-
 technical at openehr.org] On Behalf Of Bert Verhees
 Sent: 17 Ocak 2006 Sal?? 12:43
 To: openehr-technical at openehr.org
 Subject: Re: difficulties starting an implementation
 
 Hi Thomas and others,
 
 Before you start reading, I want to tell you, I think OpenEhr is a very
 valuable project, and many people want to use the concepts.
 There are however difficulties which I want to address. If sometimes my
 writings seem unpolite or harsh, please keep in mind that English is not
 my
 second language, in fact it is the fourth language I learned in my live.
 This can cause some of my expressions to be clumsy or harder then I meant
 to.
 
 I spent quite some time last week with studying the OpenEhr-website, and,
 as I
 said, it is very valuable, there are also a lot of frustrations one has to
 experience when diving into the project.
 
 I express myself with a lot of words, I often do, afraid people do not
 understand me, I do a lot of over-explaining. I admire when people can
 express themselves with not so many words, but as I see, sometimes this
 can
 also come to misunderstandings.
 This is an important subject for me, at this time, so I do not want to
 take
 risks of misunderstanding.
 
 Sometimes I also repeat myself because, different text-portions require a
 similar but slightly different approach or answer.
 
 So please be patient with me.
 
 A long introduction (I will not do it again!!)
 
 
  there is a Java ITS guide, which will be included here. The
  documentitself is available at
  http://svn.openehr.org/specification/BRANCHES/Release-1.0-
 candidate/publish
 ing/its/Java/openEHR-JavaITS.pdf
 
 This document must be new, or I just have missed it. It is for a
 programmer
 very interesting document. Such documents prevents that programmers have
 to
 re-invent things, and can prevent unnecessary branching of code and
 concepts,
 which without such information can easily happen.
 Necessary branching, which is explainable can be a good thing, but
 unnecessary
 or unintentional branching can be very bad and confusing.
 
 
   - Although there is a lot of Java-code, but it represents a previous
   version, and there is no guaranteed effort that it will be up to date
   with the official Openehr-Eiffel-code.
   It can be used as is, but for own risk for missing the project
   developments.
 
  this is correct, it is not up to date. The intention is that it will be
  brought up to date very soon after the Feb 1 publishing of Release 1.0,
  probably by my group at UCL in London.
 
 I will wait a bit with studying the code, anyway, I start studying the
 code
 when I start the project, I am thinking of. The expectation is that this
 will
 be very soon.
 
 
   - One can say, the Eiffel-code, as Thomas states somewhere, is the
   case-tool, it represents the formal state of work/definitions.
   One can create dotnet-libraries with it, which is already done. I can
   load them in my Visual Studio and Delphi.NET. But I have no way of
   checking if there is something happening behind the
   interface-properties, or if they are just there as placeholders for
   later use. My knowledge of Eiffel is really not enough for judging the
   source-files.
 
  are you talking about the ref_impl_eiffel repository? You don't have to
  use that if you are not interested in Eiffel. But I don't know what you
  mean by interface properties above...
 
 It may be a way of describing, connected

ontology, information models, archetypes - a perspective

2006-01-06 Thread Koray Atalag
Hi,

I have not been receiving messages from any of the
openehr lists since 2 months! Could you please check
this?

thanks...

-koray

--- Gerard Freriks gfrer at luna.nl wrote:

 Thomas,
 
 Thanks.
 
 What you are saying is:
 - we have the real and other worlds with objects and
 our present  
 understanding of it,
 - and we have the world where we document what has
 happened or will  
 happen.
 
 Gerard
 
 
 --  private --
 Gerard Freriks, arts
 Huigsloterdijk 378
 2158 LR Buitenkaag
 The Netherlands
 
 T: +31 252 544896
 M: +31 654 792800
 
 
 On 7-jan-2006, at 5:03, Thomas Beale wrote:
 
 
  Dear all,
 
  for those interested in how ontologies (like
 snomed-ct for  
  example), information models (like openEHR RM),
 and mediating  
  elements (archetypes, templates) can be understood
 in perspective,  
  I have produced a short powerpoint slideshow on
 the topic. See  
 

http://www.deepthought.com.au/health/tb_ontologies.ppt.
 
  - thomas beale
 
  -- 
 

__
 
  _
  CTO Ocean Informatics
 (http://www.OceanInformatics.biz)
  Research Fellow, University College London
 (http:// 
  www.chime.ucl.ac.uk)
  Chair Architectural Review Board, openEHR
 (http://www.openEHR.org)
 
 
 




  1   2   >