RE: Christmas greetings from the CKM team

[Sam Heard]

Thank you for the great report Heather. It is such a big undertaking and you 
have made a wonderful start.
Cheers, Sam

From: openEHR-clinical  On Behalf 
Of Heather Leslie
Sent: Friday, 21 December 2018 7:25 PM
To: For openEHR clinical discussions 
Cc: For openEHR technical discussions ; 
For openEHR implementation discussions 
Subject: Christmas greetings from the CKM team

Hi everyone,

What a year it has been, and great to be able to reflect back on achievements 
and the gathering momentum.

Silje Ljosland Bakke and myself, as clinical program leads would like to thank 
everyone for their contributions and efforts over the year.

Some stats to provide some insight into the ‘state of the CKM’ and activity 
over the year:

  *   Archetypes
 *   443 archetypes available, distributed over 35 projects; and a further 
102 ungoverned ones evolving in incubators
 *   In projects: 322 are draft; 26 currently undergoing review; 79 are 
published for content
 *   In the past 12 months, 16  archetypes were published; 203 archetypes 
were modified; 66 were created and added to CKM as new models
 *   Archetypes for ECG report and alcohol consumption are just on the 
brink of publication – we can expect them to be published very early in the new 
year.
  *   Templates
 *   85 templates have been submitted, mostly as examples of modelling for 
specific scenarios; 77% are in ungoverned incubators
 *   None have been reviewed to final publication status
  *   Translations
 *   Over the years there have been many archetypes that have been 
translated – we currently have representations in 24 languages, the top five 
(obviously excluding English as the default language of CKM) being:

  *   Portuguese (Brazil) - 119 archetypes translated;
  *   Norwegian Bokmal with 110;
  *   Arabic (Syria) with 78
  *   Spanish (Argentina) 51
  *   Spanish (Spain) 42
Again, a huge amount of work by a very small number of volunteers and largely 
invisible and beneath the surface.

  *   CKM users
 *   As of today, 2106 registered users from 93 countries
 *   Top five countries, by number of registered users: Brasil; UK; USA; 
Australia; Sweden
 *   278 new registrants signed up this year, purely by word of mouth. 
Imagine if we did some marketing!
  *   Reviews:
 *   749 registrants have volunteered to participate in reviews
 *   This years:
*   80 unique reviewers participated this year, 75 completing at least 
1 content review and 5 reviewers participate only in translation reviews
*   23 archetypes completed at least one review round this
*   414 archetype reviews were submitted - 375 content reviews in 39 
review rounds; 34 Swedish translation reviews in 7 review rounds
  *   We have 35 projects; 18 public incubators; 15 private incubators
  *   44 archetypes are available on a ‘view only’ basis as they are ‘owned’ by 
other collaborating CKMs – 29 referenced from the UK Apperta CKM; and 5 from 
the Norway CKM

>From an operations point of view it has been really pleasing to see activity 
>increasing and new users actively engaging in reviews.

Silje and I particularly wish to thank all those who participated as Editors – 
the ongoing effort week by week, herding cats behind the scenes and teasing out 
the patterns that make each archetype implementable is easy to underestimate 
and should not be! And to Sebastian for crafting the CKM itself that powers 
this great collaborative effort.

We thank you all for your participation and encourage those who are not yet 
active to indicate your willingness by adopting archetypes that you’d like to 
participate in for review purposes. We value any and all input. There is no 
‘stupid’ answers as everyone views the content from their own professional 
perspective and unique domain knowledge.

By volunteering your comments we have collectively created an extraordinary 
international resource, with no equal – there is no body of work in the public 
domain that is so broad and deep, and so transparent and freely available. And 
all crowd sourced from volunteer participants. Please pat yourselves on the 
back for an extraordinary effort as a community!!

The year has not been without it’s dramas and disagreements, but I am 
continuously amazed at the respect and collegiality by which people collaborate 
in meetings, on openEHR clinical Slack channels and of course, in the archetype 
reviews. Unfortunately the Slack channels are only available by invite only, so 
if you would like to be included please email me directly - 
heather.les...@atomicainformatics.com
 - and I’ll add you in:

Some big topics have been ‘nailed’ this year – in particular the Medications 
family of archetype, which has constituted a massive amount of work by editors 
and reviewers. Others that have finally been published include the tricksy 
archetypes for: Contraindication; Pulse oximetry; Problem/Diagnosis 

RE: Drug dispense entry class question

[Sam Heard]

Hi All



There is the interesting situation as to what constitutes a stop/start and an 
amend for medication. Generally, if it is the same generic substance people 
will want to see it as an amend. This means they do not have to go through all 
the warnings and search again in the database. This is probably of no 
consequence from a data point of view, apart from the fact that you do not want 
to be warned that a patient has previously been on this medication (happens in 
our system).



Cheers, Sam



Sent from Mail for Windows 10




From: openEHR-technical  on behalf 
of Thomas Beale 
Sent: Monday, August 13, 2018 9:07:18 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Drug dispense entry class question



On 11/08/2018 20:50, Karsten Hilbert wrote:
> On Sat, Aug 11, 2018 at 04:24:47PM -0300, Pablo Pazos wrote:
>
> I meant to say that some treatments will not end until the
> patient dies meaning that the COMPLETED state will never be
> reached if we take into account

certainly true in theory, and maybe in reality. But drug treatments
change and different variants may be tried over time - true even for
basics like insulin - so at least for some chronic medication
situations, it probably will be the case that one treatment finishes and
another starts, based on a (?slightly) different order, with this
repeating over time.

- 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

RE: The openEHR Asia summit succeeded.

[Sam Heard]

Congratulations Shinji

It is your commitment and continuity that has made such a difference. I hope to 
attend the next meeting.

Cheers, Sam



Sent from Mail for Windows 10




From: openEHR-clinical  on behalf 
of Shinji KOBAYASHI 
Sent: Monday, July 30, 2018 9:28:31 PM
To: For openEHR clinical discussions; For openEHR technical discussions; For 
openEHR implementation discussions
Subject: The openEHR Asia summit succeeded.

Dear openEHR colleagues,

We completed all the schedule for the first openEHR Asia summit, and
the second general assembly of Japan.
We also celebrated the new board member, Xudong Lu with many kampais.
Congratulations.
In Asia, openEHR activities are supported with ground roots, and
growing steadily.
Dr Ryan Bannez showed his beautiful EMR system based on Marand
EhrScape in Philippines, and 40 clinics adopted that.
Prof Xudong Lu showed 5 big projects plan in China.
I presented openEHR Japan activity and nation-wide EHR project in
Japan, that involving 75 hospitals.
The next openEHR Asia summit will be in China in the next year.

Best regards,
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: Quantities of arbitrary units in openEHR

[Sam Heard]

Hi All

The 'property' editor is available with the archetype editor. Has anyone had
a look at adding the required type and then the whatever bit can be in all
the tools.

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Sebastian Garde
Sent: Thursday, 25 January 2018 7:33 PM
To: For openEHR technical discussions 
Subject: AW: Quantities of arbitrary units in openEHR

 


This sender failed our fraud detection checks and may not be who they appear
to be. Learn about spoofing  

Feedback  

Hi Silje,

 

I think this may 'just' be a modelling tooling issue, openEHR itself
supports this ok.

 

Speaking for CKM, if you upload an archetype with this to CKM, it should
validate the UCUM unit correctly for [arb'U]{whatever}.

However, [arb'u]{whatever} or similar is (very slightly) incorrect in my
understanding:

 

1.  Use the completely vertical ' not ' or similar (at least that is my
understanding).
2.  openEHR uses (implicitly I think, but it may be hidden somewhere in
the spec), the case-sensitive version of UCUM - therefore the U needs to be
upper case, see e.g. http://unitsofmeasure.org/ucum.html#para-45

 

Regards

Sebastian

 

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
Im Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 10:25
An: openehr-technical@lists.openehr.org
 
Betreff: Re: Quantities of arbitrary units in openEHR

 

Hi Silje,

I don't understand how adding an 'Arbitrary' term to the openEHR terminology
helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange
units just turn up in the String form you quoted for UCUM arbitrary units in
that field?

(BTW, to ask for a new terminology term, just create a new issue on the PR
tracker with component=New Term Request - choose this from the dropdown).

Setting property and not units makes sense - and if we had a proper,
standardised units service, a runtime archetype evaluator would use it to
limit the actual units for property = pressure (say) to only pressure units.
I think we need to define such a service properly

- thomas

 

On 24/01/2018 09:52, Bakke, Silje Ljosland wrote:

Hi all,

 

I'm working on representing medication strengths in archetypes at the
moment. Most medications are thankfully measured in SI units such as mg/ml
or mg/{dose unit}, but others use arbitrary units that are not derived from
any other physical dimensional units. Examples of these are standardized
quality units (SQ-U), focus forming units (FFU), European and American
pharmacopoeia units, anti factor Xa units, or international units (IU).
There are seemingly an unlimited number of these units, and they apparently
make up new ones as they go along (ref: SQ-T and SQ-HDM). See
http://unitsofmeasure.org/ucum.html#para-45 for more.

 

UCUM has a generic way of representing these, as "[arb'u]{whatever}"
(arbitrary unit, name of the unit), but openEHR doesn't seem to have a
property in its Quantity data type for them. Could it be a possibility to
add an "Arbitrary" property to the openEHR support terminology for unit
properties?

 

Also, is it ok to model Quantity elements with a property set but the units
left unconstrained? I've just started trying to add these units to an
archetype (as a concentration, so got around the property issue), and it's
just a never ending task. 

 

Kind regards,
Silje Ljosland Bakke

 

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway

Tel. +47 40203298

Web:   http://arketyper.no / Twitter:
 @arketyper_no

 





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

 

-- 
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: Process to follow for coding using Terminology server

[Sam Heard]

Hi Dileep

There is also the Mappings attribute set which allows you to code but without 
changing the text to the definition in the terminology. You can then code 
something in a range of terminologies.

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Dileep V S
Sent: Wednesday, 20 December 2017 7:04 PM
To: For openEHR technical discussions 
Subject: Re: Process to follow for coding using Terminology server

 

Thanks Ian,

 

I tested and it works. Your detailed explanation was a great help. I am sure 
you will make a very good teacher. Though Pablo also said the same thing 
first, I did not fully get it.

 

 

regards





   


Dileep V S


Founder


HealtheLife Ventures LLP


m:

+91 9632888113


a:

103, Innovation Centre, IIIT, Electronics City, Bangalore 560100


w:

  healthelife.in  e:   
dil...@healthelife.in

 

On Wed, Dec 20, 2017 at 2:03 PM, Ian McNicoll  > wrote:

Hi Dileep,

 

As Pablo says, any DV_TEXT can be sub-classed as DV_CODED_TEXT.

 

How are you storing the composition data ,FLAT JSON?

 

If so you can save coded data for any DV_TEXT node as follows

 

  
"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent|code":
 "91936005",

  
"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent|value":
 "allergy to penicillin",

  
"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent|terminology":
 "SNOMED-CT",

 

 
"adverse_reaction_list/allergies_and_adverse_reactions/adverse_reaction_risk:0/causative_agent":
 "non-coded text",

 

The fulll RAW JSON equivalent is

 

{

"@class": "ELEMENT",

"name": {

"@class": "DV_TEXT",

"value": "Causative agent"

},

"archetype_node_id": "at0002",

"value": {

"@class": "DV_CODED_TEXT",

"value": "allergy to penicillin",

"defining_code": {

"@class": "CODE_PHRASE",

"terminology_id": {

"@class": "TERMINOLOGY_ID",

"value": "SNOMED-CT"

},

"code_string": "91936005"

}

}

},

 

AQL to retreive is something like

 

  b_a/data[at0001]/items[at0002]/value/value as causative_agent_value,

b_a/data[at0001]/items[at0002]/value/defining_code/code_string as 
causative_agent_code,

b_a/data[at0001]/items[at0002]/value/defining_code/terminology_id/value as 
causative_agent_terminology,

 

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 20 December 2017 at 05:41, Dileep V S  > wrote:

Hi,

 

We are in the process of adding a terminology server to code the composition 
date. However many of the nodes that can be coded are text fields (Eg. 
Symptom/sign name in Symptom/sign archetype that we have used in Complaints 
template). As we understand, the data type has to be changed to CODED-TEXT 
before we can store coded data.

 

What is the best practice to do this? Shall we go ahead and edit the 
archetypes, in which case our archetypes will no longer be same as the ones in 
CKM? Are there more robust mechanisms to achieve this without breaking 
compliance to CKM?

 

regards



   


Dileep V S


Founder


HealtheLife Ventures LLP


m:

+91 9632888113  


a:

103, Innovation Centre, IIIT, Electronics City, Bangalore 560100


w:

  healthelife.in  e:   
dil...@healthelife.in

 

___
openEHR-technical mailing list

RE: Scenarios for change type "deleted"

[Sam Heard]

Hi All

Ideas from a clinical perspective:

  1.  A patient or clinician may want to delete a composition from one instance 
of a health record. For example, a correspondence about a surgical operation 
(which is considered sensitive by a patient) might come to a mental health 
service and be added to their record at that site. The patient may ask for it 
to be removed as it is not relevant at that location.
  2.  A patient may want something deleted from their ‘virtual EHR’ or single 
logical record. This will be more difficult and should be deemed to be an error 
of some sort, or have expired from a medicolegal point of view. A label like ‘ 
personality disorder’ entered by an inexperienced nurse at an emergency clinic 
might be an example. Clearly propagating the update of the entire EHR will 
depend on the governance of each instance. We will have to have very clear 
rules for this to be automated and safe. It will, however, always be possible 
to return the record to the state it was at any given interaction.
  3.  A patient may want to delete (or recall) all propagated copies of a 
composition. This would appear to be reasonable, especially in an “opt out” 
situation like we have in Australia. This does not have the medicolegal issue 
that item 2 has as the record will be held in the ecosystem in which it was 
created. However, a trust system will still be required or very strong 
governance of who can propagate such a deletion.
Cheers, Sam

Sent from Mail for Windows 10


From: openEHR-technical  on behalf 
of Bert Verhees 
Sent: Sunday, November 5, 2017 3:15:09 PM
To: For openEHR technical discussions
Subject: Re: Scenarios for change type "deleted"


Here is the a description by royal organization of medical institutions of the 
Dutch law for saving medical data.
https://www.knmg.nl/advies-richtlijnen/artseninfolijn/praktijkdilemmas-1/praktijkdilemma/hoe-lang-moet-ik-medische-dossiers-van-patienten-bewaren.htm

It was years ago 10 years. It is now 15 years. Dutch law is always harmonised 
with European or UN law if there is such law on that level.

There are two considerations.
1) The medical institutions want an end point for their responsibilities to 
keep data access able.
2) Patients have the right to clean up their history.

The medical institution is not required to remove the data after 15 years but 
it has the right to do that. 10 years ago I wrote software to facilitate that 
for the largest GP software user group of the Netherlands.

After those 15 years a patient can demand totally removal of every trace at a 
medical institution.

So. This to close that part of the discussion.

I did not read yet Pablo 's long reply. I will certainly do that maybe later 
today. I am again travelling.

Best regards
Bert

Op zo 5 nov. 2017 00:26 schreef Pablo Pazos 
>:
On Thu, Nov 2, 2017 at 3:01 PM, Thomas Beale 
> wrote:

On 15/10/2017 12:49, Pablo Pazos wrote:
Hi I'm trying to define a set of rules for a logical delete commit and have 
some gray areas that I'm not sure of.

1. commit after delete flow

[creation v1] => [modification v2] => [deleted v3] => ?

Can a modification/amendment v4 happen after a delete?

well, a deletion is a deletion, logically. In a non-versioned system, the data 
object would literally disappear.

Logical deletions don't make data disappear, even if it's not under a versioned 
system.

In a versioned system, such as we have, the top version records the fact of 
deletion, which logically applies to the whole versioned object.

That sort of works on a lineal versioned system, the specs are not clear in 
terms of how to handle a deletion in a distributed versioned system.

I agree delete should be considered to affect the status of the whole versioned 
object, but on a branching scenario this is not so well defined or maybe can't 
be implemented at all (see below ***).

The issue I see with versioning for deletion is that amendments, modifications, 
etc. are defined at the same level of the deletions, and the other modification 
types apply to the latest version, not to the whole composition. Considering 
this: shouldn't delete be specified on it's own, separated from other change 
types?

I always had doubts about using a commit to delete something, and now I'm 
starting to understand why :)



This is one of those cases that forks in the version tree can happen, since v2 
is deleted by v3, but v1 can be forked and a commit of modification or 
amendment can happen on that branch.

it could, if in system A (say in hospital A), the Composition is logically 
deleted but in system B (clinic B) a copy of that Composition (say medications 
list) is modified with a new version; then if this modified Versioned object is 

RE: Adverse reaction archetype... just published

[Sam Heard]

Congratulations to all, a big topic and enabler.
Sam

Sent from my Windows Phone

From: Heather Leslie
Sent: ‎19/‎11/‎2015 7:02 PM
To: For openEHR clinical 
discussions; For openEHR 
implementation discussions; For 
openEHR technical discussions
Subject: Adverse reaction archetype... just published

Hi everyone,

Just a quick note to let you know that the Adverse Reaction archetype has been 
published.

The evolution of the archetype from its first iteration uploaded in July 2008 
and first ever review in July 2009 through to today has been fragmented and a 
bit ‘staccato’ with review contributions coming from the openEHR, NEHTA and 
Nasjonal IKT CKMs at various times through the process, culminating in 
publication in the international openEHR CKM. I expect that Norway is likely to 
follow suit very soon, others will utilise it at their own pace.

This published archetype is the result of activity in each of the openEHR, 
NEHTA and Nasjonal IKT CKMs:

  *   Activity:
 *   First review round 2009 (openEHR)
 *   5 Review rounds Nov 2010 to Jul 2011 (NEHTA)
 *   Further review round 2012 (openEHR)
 *   4 joint review rounds with FHIR community from Jul 2014-Nov 2015 
(openEHR)
 *   1 parallel review round by Nasjonal IKT in Norwegian language Jun-Sep 
2015 (Norway CKM)
  *   12 Review rounds completed in total, comprising
 *   91 individuals participated from 16 countries
 *   182 individual reviews
  *   0 face to face meetings! All work was done online, including Editorial 
facilitation of reviewer feedback.

And this is definitely our most complex archetype published to date. It is a 
ubiquitous concept, but implemented in many different ways and contexts, and 
the added requirement that flexible extensions will be required for aligned 
activities such as reporting to government or for clinical trial data.

It is anticipated that an aligned FHIR resource will be made available based on 
the common clinical content collaboration.

An absolutely phenomenal effort from everyone!

Now we move on to the Medication family of archetypes in the next few days – 
another extraordinarily complex modelling feat that is currently being 
coordinated by Ian McNicoll. If you would like to participate please adopt the 
archetypes you would like to review: 
http://www.openehr.org/ckm/#showProject_1013.30.27

Kind Regards

Heather

Dr Heather Leslie MBBS FRACGP FACHI
Consulting  Lead, Ocean Informatics
Clinical Programme Lead, openEHR Foundation
p: +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: New paper: Archetype-based data warehouse environment

[Sam Heard]

Congratulations David and to you wonderful colleagues.
Cheers, Sam

Sent from Windows Mail

From: David Monermailto:dam...@gmail.com
Sent: ?Friday?, ?19? ?June? ?2015 ?5?:?37? ?PM
To: For openEHR clinical 
discussionsmailto:openehr-clini...@lists.openehr.org, For openEHR technical 
discussionsmailto:openehr-technical@lists.openehr.org

Dear all,

My colleagues Luis Marco-Ruiz, Jos? A. Maldonado, Nils Kolstrup, Johan G. 
Bellika and myself have just published a paper titled Archetype-based data 
warehouse environment to enable the reuse of electronic health record data in 
the International Journal of Medical Informatics. I think this work can be of 
interest for many of you.

Best regards,
David

Link: http://www.sciencedirect.com/science/article/pii/S1386505615300058

Abstract:

- Background. The reuse of data captured during health care delivery is 
essential to satisfy the demands of clinical research and clinical decision 
support systems. A main barrier for the reuse is the existence of legacy 
formats of data and the high granularity of it when stored in an electronic 
health record (EHR) system. Thus, we need mechanisms to standardize, aggregate, 
and query data concealed in the EHRs, to allow their reuse whenever they are 
needed.
- Objective. To create a data warehouse infrastructure using archetype-based 
technologies, standards and query languages to enable the interoperability 
needed for data reuse.
- Materials and methods. The work presented makes use of best of breed 
archetype-based data transformation and storage technologies to create a 
workflow for the modeling, extraction, transformation and load of EHR 
proprietary data into standardized data repositories. We converted legacy data 
and performed patient-centered aggregations via archetype-based 
transformations. Later, specific purpose aggregations were performed at a query 
level for particular use cases.
- Results. Laboratory test results of a population of 230,000 patients 
belonging to Troms and Finnmark counties in Norway requested between January 
2013 and November 2014 have been standardized. Test records normalization has 
been performed by defining transformation and aggregation functions between the 
laboratory records and an archetype. These mappings were used to automatically 
generate open EHR compliant data. These data were loaded into an 
archetype-based data warehouse. Once loaded, we defined indicators linked to 
the data in the warehouse to monitor test activity of Salmonella and Pertussis 
using the archetype query language.
- Discussion. Archetype-based standards and technologies can be used to create 
a data warehouse environment that enables data from EHR systems to be reused in 
clinical research and decision support systems. With this approach, existing 
EHR data becomes available in a standardized and interoperable format, thus 
opening a world of possibilities toward semantic or concept-based reuse, query 
and communication of clinical data.


--
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Problem with version and specialisation

[Sam Heard]

My take on this is that such archetypes need to be fairly inclusive and stable, 
using templates to constrain.

There is no guarantee that versions will remain compatible. As revisions are 
only extensions, this should work. Versioning (breaking change for existing 
data , needs to be limited to when there is real benefit as software will need 
to change.

Cheers Sam

Sent from my Windows Phone

From: jacky.lauchunkin at gmail.commailto:jacky.lauchun...@gmail.com
Sent: ?22/?09/?2014 10:47 AM
To: openehr-technicalmailto:openehr-technical at lists.openehr.org
Subject: Problem with version and specialisation

Dear All,
I met a problem when using specialisation and version.
For example, I have two archetypes, openEHR-DEMOGRAPHIC-PERSON.patient.v1 
and openEHR-DEMOGRAPHIC-PERSON.patient-specialise.v1. Archetype 
openEHR-DEMOGRAPHIC-PERSON.patient-specialise.v1 is specialised from 
openEHR-DEMOGRAPHIC-PERSON.patient.v1. Let's say the archetype 
openEHR-DEMOGRAPHIC-PERSON.patient-specialise.v1 have modified for several 
times and its current version is v3. And now 
openEHR-DEMOGRAPHIC-PERSON.patient.v1 has upgraded to version 2, 
openEHR-DEMOGRAPHIC-PERSON.patient.v2. Can I simply upgrade 
openEHR-DEMOGRAPHIC-PERSON.patient-specialise.v3 to version 4 so that I can 
change its specilisation to openEHR-DEMOGRAPHIC-PERSON.patient.v2?


Best wishes!
Jacky.Lau
2014-09-19
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140922/b17a8193/attachment.html

MedInfo 2015 openEHR tutorials

[Sam Heard]

Hi Pablo

I wonder if Jusara could organise a submeeting in an academic/industry forum 
prior to MedInfo?

Cheers Sam

Sent from Windows Mail

From: pablo pazosmailto:pazospa...@hotmail.com
Sent: ?Saturday?, ?2? ?August? ?2014 ?9?:?06? ?AM
To: For openEHR clinical discussionsmailto:openehr-clinical at 
lists.openehr.org, For openEHR technical discussionsmailto:openehr-technical 
at lists.openehr.org
Cc: For openEHR implementation discussionsmailto:openehr-implementers at 
lists.openehr.org

Thanks for the info Heather!

I think we should do something similar to the previous workshops for devs, 
something simple to get newcomers to understand how to work with archetypes in 
software (parsing, processing, validating data, extracting paths, etc), and 
more specific topics for skilled openEHR devs (persistence options, REST APIs, 
querying, reporting, UI generation, ...).

I would love to see a hands-on tutorial in which we can program live and help 
newcomers to pass the first barrier in openEHR software development: lose the 
fear of archetypes.

Also I would like to know how we want to present this, should we submit the 
proposals individualy and then organize or should we coordinate and make one 
proposal with all the workshops/tutorials?

Thanks!

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.comhttp://cabolabs.com/es/homehttp://twitter.com/ppazos


From: heather.les...@oceaninformatics.com
To: openehr-technical at lists.openehr.org; openehr-clinical at 
lists.openehr.org
Subject: RE: MedInfo 2015 openEHR tutorials
Date: Fri, 1 Aug 2014 01:54:59 +
CC: openehr-implementers at lists.openehr.org


Hi Pablo,



We have kept info on Conferences in the wiki: 
http://www.openehr.org/wiki/display/resources/Conferences



See Medinfo 2013: 
http://www.openehr.org/wiki/display/resources/MEDINFO+2013+-+Copenhagen,+Denmarkhttp://www.openehr.org/wiki/display/resources/MEDINFO+2013+-+Copenhagen%2c+Denmark.
 2 half day sessions were held then - one clinical modelling focussed and the 
other technical



Regards



Heather



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Friday, 1 August 2014 12:14 AM
To: openeh technical; openEHR Clinical
Cc: openehr implementers
Subject: RE: MedInfo 2015 openEHR tutorials



Hi Shinji!



By chance, do you have the agendas of the previous openEHR developer's 
workshops?



It would be nice to see what has been done, do a little bit of introduction 
workshops for beginners and do some new cool stuff for skilled openEHR devs.



BTW, maybe a good place to coordinate and share info about ideas would be the 
openEHR wiki.



Thanks!

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



From: skoba at moss.gr.jpmailto:sk...@moss.gr.jp
Date: Wed, 30 Jul 2014 10:25:16 +0900
Subject: Re: MedInfo 2015 openEHR tutorials
To: openehr-clinical at lists.openehr.orgmailto:openehr-clinical at 
lists.openehr.org
CC: openehr-technical at lists.openehr.orgmailto:openehr-technical at 
lists.openehr.org; openehr-implementers at 
lists.openehr.orgmailto:openehr-implementers at lists.openehr.org

Hi Pablo and all,

We had developers' workshop at Medinfo2007, 2010 and 2013, and I organized 
developers' workshop 2010, and 2013.

I think the combination of clinical workshop/tutorial half day and developers' 
workshop half day would be better.

I have to write up until the tutorial/workshop dead line, 15 Jan, 2015.

Shinji KOBAYASHI



2014-07-29 13:52 GMT+09:00 pablo pazos pazospablo at 
hotmail.commailto:pazospablo at hotmail.com:

Hi all!



Since next MedInfo is in Brazil (near Uruguay) I'll be attending for sure. I 
also might present a paper or two and want to propose an openEHR related 
tutorial.



Is other people planning to present openEHR papers or tutorials? It would be 
great if we can coordinate tutorials (and topics) together so we can have our 
openEHR day at MedInfo.



What do you think?



We have 1 year to plan this, and that's not a lot of time!



I hope we can join forces and do something nice for the south american openEHR 
community. We are eager to learn from others that already have openEHR working 
in the real world, and learn from their success and failures.

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

___
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



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

___ openEHR-clinical mailing 

MedInfo 2015 openEHR tutorials

[Sam Heard]

Hi Pablo

Great to hear from you and your plans for Medinfo 2015. I plan to come for the 
meeting and I am sure a lot of others do too. A group of openEHR implementers 
will be meeting in Istanbul before MIE on the Saturday afternoon (venue to be 
decided).

I would hope that there will be sufficient momentum in Brazil to have a high 
profile openEHR stream at Medinfo and take a key role in the conference.

Cheers, Sam

Sent from Windows Mail

From: Pablo Pazosmailto:pazospa...@hotmail.com
Sent: ?Tuesday?, ?29? ?July? ?2014 ?2?:?23? ?PM
To: For openEHR clinical discussionsmailto:openehr-clinical at 
lists.openehr.org, For openEHR implementation 
discussionsmailto:openehr-implementers at lists.openehr.org, For openEHR 
technical discussionsmailto:openehr-technical at lists.openehr.org

Hi all!

Since next MedInfo is in Brazil (near Uruguay) I'll be attending for sure. I 
also might present a paper or two and want to propose an openEHR related 
tutorial.

Is other people planning to present openEHR papers or tutorials? It would be 
great if we can coordinate tutorials (and topics) together so we can have our 
openEHR day at MedInfo.

What do you think?

We have 1 year to plan this, and that's not a lot of time!

I hope we can join forces and do something nice for the south american openEHR 
community. We are eager to learn from others that already have openEHR working 
in the real world, and learn from their success and failures.

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.comhttp://cabolabs.com/es/homehttp://twitter.com/ppazos
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140729/d0e707bb/attachment.html

openEHR-technical Digest, Vol 18, Issue 37

[Sam Heard]

Hi William

That road is seductive but assumes that SNOmed or the like covers the concept 
unambiguously. The fact is that the world experts on SNOMED spent weeks 
discussing what codes applied to the BP archetype nodes.and finally agreed 
with the ones I had proposed.

The fact is that the archetypes are often far less ambiguous than the terms in 
an ontology.

Modeling in openEHR will accelerate now we have a widening implementation base. 
The models won't be perfect or all encompassing but they will support high 
fidelity processes and sharing evolving data expressions.

Ontological based approaches may be suitable in 20 years, but will need to be 
based on the clinical models, not the other way around. Clinicians need to 
define what they want to record.

My 2p - Cheers Sam

Dr Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
+61417838808

From: William Goossenmailto:wgoos...@results4care.nl
Sent: ?28/?08/?2013 6:16 PM
To: openehr-technical at lists.openehr.orgmailto:openehr-technical at 
lists.openehr.org
Cc: openehr-technical at lists.openehr.orgmailto:openehr-technical at 
lists.openehr.org
Subject: Re: openEHR-technical Digest, Vol 18, Issue 37

The General problem with the at codes is that each archetype has the same at 
codes. Hence it is not an ontology it refers to but is an internal 
micro-ontology only .

In the DCM approach each node SHALL have a minimum of one external code, 
preferable Snomed CT, which links the data element in the archetype to an 
external ontology, which importantly allows external maintenance and governance 
and facilitates the use in other archetypes or templates as defined in OpenEHR.

Vriendelijke groet,

Dr. William Goossen

Directeur Results 4 Care BV
+31654614458

Op 28 aug. 2013 om 18:00 heeft openehr-technical-request at lists.openehr.org 
het volgende geschreven:

 Send openEHR-technical mailing list submissions to
openehr-technical at lists.openehr.org

 To subscribe or unsubscribe via the World Wide Web, visit

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

 or, via email, send a message with subject or body 'help' to
openehr-technical-request at lists.openehr.org

 You can reach the person managing the list at
openehr-technical-owner at lists.openehr.org

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of openEHR-technical digest...


 Today's Topics:

   1. Re: Polishing node identifier (at-codes) use cases.
  (Gerard Freriks)


 --

 Message: 1
 Date: Wed, 28 Aug 2013 13:26:14 +0200
 From: Gerard Freriks gfrer at luna.nl
 To: For openEHR technical discussions
openehr-technical at lists.openehr.org
 Subject: Re: Polishing node identifier (at-codes) use cases.
 Message-ID: C6BF076F-3040-442B-B9D7-69D04EEC599A at luna.nl
 Content-Type: text/plain; charset=windows-1252

 David,

 Can I summarise it for my understanding as:
 - AT codes are pointers to an 'ontology'.
 - AT codes can be considered symbols that represent a particular concept
 - The 'ontology' provides a name that will be used to display the name of a 
 node (concept) in an archetype.
 - When a node is specialised the node name used will indicate a new concept 
 (its meaning has changed)
 - When the archetype is specialised ideally the new concept in the 
 specialisation is a subordinate concept.
 - When a Node is specialised the standard does not prescribe that the new 
 concept is a sub-set of the previous one.
 - The question is: is each Node (and the concept it represents) unique or not.
 - The question is: is it obligatory that each node in the archetype carries a 
 unique code  of the form AT .

 My answers to both questions are:
 - Each archetype node is  a unique concept that must have attached to it a 
 unique identifier.
 - Archetype editors must support this.

 And I would like to add:
 - When specialising each specialised concept must be a subset of its previous 
 one.


 Gerard Freriks
 +31 620347088
 gfrer at luna.nl

 On 28 aug. 2013, at 09:13, David Moner damoca at gmail.com wrote:


 I'll try to summarize the origin of the different views we have regarding 
 this topic and maybe this can be also useful to see why this is not just a 
 configuration problem of the tools.

 We can find the explanation of node identifiers in two places (I use the 
 latest drafts, I think):
 - In AOM 1.5 specifications, page 47: Semantic identifier of this node, 
 used to distinguish sibling nodes of the same type. [Previously called 
 ?meaning?]. Each node_id must be defined in the archetype ontology as a term 
 code.
 - In ADL 1.5 specifications, page 26: In cADL, an entity in brackets of the 
 form [at] following a type name is used to identify an object node, i.e. 
 a node constraint delimiting a set of instances of the type

Re: Regarding the use of the Demographics Package...

[Sam Heard]

Hi Anthanasios - Heath has been doing something like that



Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Consultant  Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
Senior Visiting Research Fellow, University College London



From: Athanasios Anastasiou
Sent: ?Monday?, ?1? ?July? ?2013 ?9?:?00? ?PM
To: Openehr-Technical


Hello everyone

Would it be good practice to use the demographics package to describe
both the patients for which data are available in a system but also the
users of the system?

As far as the first part is concerned, the demographics package provides
a very good level of detail for describing the parties that could be
involved in healthcare provision for some event.

However, was / is there also the intention of using the same demographic
entities data store to perform authentication / access control too?

(I am thinking of:
a) A pre-condition for an operation to be carried out on the existence
of specific PERSON.roles or membership of a PERSON into some GROUP
(which is straightforward); and

b) Providing something like a ROLE(meaning=canLogin) with an
associated CAPABILITY.credentials Archetype that could be used to
perform authentication...Besides the trivial example of having a CLUSTER
with clear text username / password, there could be an Archetype with
just enough information to authenticate a user against an external
service (e.g. an LDAP directory) In this case, the Archetype would not
store username / passwords, just enough information required to connect
to the component that will be performing the authentication to retrieve
a simple yes/no answer at the time of logging in) )

Looking forward to hearing from you
Athanasios Anastasiou




This email and any files with it are confidential and intended solely for the 
use of the recipient to whom it is addressed. If you are not the intended 
recipient then copying, distribution or other use of the information contained 
is strictly prohibited and you should not rely on it. If you have received this 
email in error please let the sender know immediately and delete it from your 
system(s). Internet emails are not necessarily secure. While we take every 
care, Plymouth University accepts no responsibility for viruses and it is your 
responsibility to scan emails and their attachments. Plymouth University does 
not accept responsibility for any changes made after it was sent. Nothing in 
this email or its attachments constitutes an order for goods or services unless 
accompanied by an official order form.

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130701/36dfd873/attachment.html

TDS (and TDD) implementations?

[Sam Heard]

Hi
We designed the process to allow ant XML schema generated to be transformed to 
openEHR with a single transform.

I expect it may well be possible to do the reverse. At least it would be 
possible to get to a consistent flattened form.

The reason for the TDS is to validate data using XML tools.

Cheers Sam

Dr Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
+61417838808

From: Daniel Karlssonmailto:daniel.karls...@liu.se
Sent: ?14/?06/?2013 5:12 PM
To: openehr-technical at lists.openehr.orgmailto:openehr-technical at 
lists.openehr.org
Subject: Re: TDS (and TDD) implementations?

Hi Ian,

On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote:
 Hi Erik,


 The Ocean TDD-canonical transform is available at


 http://openehr.codeplex.com/SourceControl/latest#176376



 look for TDD_to_openEHR.xsl


 As far as I know a generic reverse transform is not possible.

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

/Daniel


 There are at least 3 or 4 companies using TDD as part of their CDR
 offering.


 It would be good to make this part of the managed standard and public
 spec .


 Ian



 On 30 May 2013 10:21, Erik Sundvall erik.sundvall at liu.se wrote:
 Hi!


 Which projects and products out there support TDS (Template
 Data Schema)? And do they support conversion of TDDs (Template
 Data Documents) to standard canonical openEHR RM instances
 (in e.g. XML)? Is there any available XSLT, webservice or
 other thing that can convert bidirectionally between TDD and
 openEHR RM-based instances?


 What about a TDS specification? Is there any published or
  work-in-progress document? If not is there any entity, group
 or person that could/should be sponsored or bribed to produce
 such a thing? :-) It seems to be on the
 roadmap http://www.openehr.org/programs/specification/roadmap and 
 described there anyway...


 I think TDS is an essential component in the toolbox in
 practical openEHR integration projects but without a public
 spec, it will be harder to take seriously and hard to make
 compatible implementations.


 (ExampleTDS-info for people not familiar with the
 approach: 
 http://www.mz.gov.si/fileadmin/mz.gov.si/pageuploads/eZdravje/Novice/gradiva_predstavitve_dogodkov/Open_EHR/7_integration.pdf)


 Best regards,
 Erik Sundvall
 Tel: +46-72-524 54 55
 LiO: erik.sundvall at lio.se 
 http://www.lio.se/Verksamheter/IT-centrum/
 LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/

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




 --
 Dr Ian McNicoll
 office +44 (0)1536 414 994
 fax +44 (0)1536 516317
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com

 Clinical Modelling Consultant, Ocean Informatics, UK
 Director openEHR Foundation  www.openehr.org/knowledge
 Honorary Senior Research Associate, CHIME, UCL
 SCIMP Working Group, NHS Scotland
 BCS Primary Health Care  www.phcsg.org

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



___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/c0e3ea26/attachment-0001.html

Re: Trying to understand the openEHR Information Model

[Sam Heard]

Hi Randy


I guess it does so far at least. I guess there will only be a few back end 
openEHR servers in the future, one or two of which are likely to be open source.


The idea is that the query layer is further away from the implementation layer 
than is usual for a health care system. The way the openEHR data can be stored 
is still an experimental science.


Ocean has an AQL parser which then queries the openEHR repository and is now 
optimised in a number of ways. Some of these are independent of the storage 
mechanism entirely. 


Cheers, Sam



Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Consultant  Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
Senior Visiting Research Fellow, University College London



From: Randolph Neall
Sent: ?Saturday?, ?20? ?April? ?2013 ?12?:?37? ?AM
To: For openEHR technical discussions



Seref, to add to my questions:



 AQL is the most neglected, yet, probably one of the most important components 
 of an openEHR implementation.
 


Does this imply that each implementation of openEHR is sufficiently different 
from others as not to allow for easy sharing of such things as search or 
storage technologies? 




Randy




On Thu, Apr 18, 2013 at 6:09 AM, Thomas Beale thomas.beale at 
oceaninformatics.com wrote:




On 17/04/2013 22:04, Randolph Neall wrote:



Thomas, somehow I'm not finding the AQL specification. It's probably right 
under my nose on your specification/release page. Also, do you have any 
references describing the AQL processor? Did you write that from scratch?? It 
would seem that the AQL processor would indeed function as a formidable DBMS in 
its own right, at least with regard to reads, capable of managing AND/OR logic 
trees and serving up flat tables of joined data structures like any RDBMS. 



Randy 




http://www.openehr.org/wiki/display/spec/AQL-+Archetype+Query+Language

- thomas


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130420/0e9da195/attachment.html
-- next part --
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Guideline Definition Language (GDL) specifications and GDL-editor release announcement

[Sam Heard]

Congratulations Ring

Thanks for taking such a great leading position with openEHR, which only gets 
stronger with time.

We need to think about how to integrate this in the CKM space so the rules can 
be shared when appropriate.

Cheers Sam

Dr Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
+61417838808

From: Rong Chenmailto:rong.c...@cambio.se
Sent: ?12/?03/?2013 1:28 AM
To: openEHR-technical at lists.openehr.orgmailto:openEHR-technical at 
lists.openehr.org; openEHR-clinical at 
lists.openehr.orgmailto:openEHR-clinical at lists.openehr.org; 
openehr-implementers at lists.openehr.orgmailto:openehr-implementers at 
lists.openehr.org
Subject: Guideline Definition Language (GDL) specifications and GDL-editor 
release announcement

Dear all,

We are pleased to announce the immediate availability of the design 
specifications of Guideline Definition Language (GDL) and its reference 
implementation under open source software licenses. GDL is formal language 
designed to express and to share Clinical Decision Support rules across 
language and technical barriers by leveraging openEHR designs. CDS rules in GDL 
format is agnostic to natural languages, reference terminologies and rules 
engine languages.

There are considerable synergies in the development of clinical models and CDS 
rules. Semantically well-defined clinical models can provide reliable means of 
input and output of the rules. On the other hand, experiences from CDS rules 
development can lead to improvements of the clinical models as well as 
increased motivations to adopt structured and standardized clinical models. 
Reusing existing high-quality clinical models in the form of archetypes would 
hopefully increase the productivity in authoring and maintaining clinical rules.

Please note that GDL is still in development. We aim to submit the GDL 
specifications for review in openEHR in the near future. We look forward to the 
community's feedback to further improve the specifications.

Some important links from this release:

1.   GDL Specifications 
(v.90)https://github.com/openEHR/gdl-tools/blob/master/cds/docs/specs/gdl-specs.pdf?raw=true

2.   GDL Editorhttp://sourceforge.net/projects/gdl-editor/

3.   GDL sample 
fileshttps://github.com/openEHR/gdl-tools/tree/master/cds/cm/guides

4.   GDL Reference Implementation 
Projecthttps://github.com/openEHR/gdl-tools/wiki

Rong Chen
On behalf of the Informatics Team,
Cambio Healthcare Systems, Sweden


Rong Chen, MD, PhD
CMIO, Director of Health Informatics
+46 8 691 49 81

Cambio+ Healthcare Systems AB
Stockholm:
Ringv?gen 100. SE-118 60 Stockholm
Vx: +46 8 691 49 00 | Fax: +46 8 691 49 99
Link?ping:
Brigadgatan 14. SE-587 58 Link?ping
Vx: +46 13 20 03 00 | Fax: +46 13 20 03 99
Epost: info at cambio.semailto:info at cambio.se | Hemsida:www.cambio.se

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130312/65a5a4de/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 146 bytes
Desc: image001.png
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130312/65a5a4de/attachment.png
-- next part --
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Guideline Definition Language (GDL) specifications and GDL-editor release announcement

[Sam Heard]

Hi Rong - noticed the Typo (Ring) - it seems I have trouble with names of 
people in Sweden!

Cheers, Sam 



Sent from Windows Mail


From: Rong Chen
Sent: ?12? ?March? ?2013 ?10?:?09? ?PM
To: For openEHR implementation discussions, For openEHR technical discussions, 
openEHR-clinical at lists.openehr.org
Subject: RE: Guideline Definition Language (GDL) specifications and GDL-editor 
release announcement




Hi Sam and all,

 

Thanks for the positive feedbacks so far. We really appreciate that.

 

Personally I am very fond of the idea to host GDL rules in CKM. CKM?s support 
of change management, distributed review, indexing and search, translation and 
release sets management (including archetypes/templates, rules and term 
refsets) will immediately benefit the development of rules.

 

Cheers,

Rong

 


Rong Chen, MD, PhD

CMIO, Director of Health Informatics

+46 8 691 49 81 

cid:image001.png at 01CE14CE.DC7B4E10 

Cambio+ Healthcare Systems AB 

Stockholm: 

Ringv?gen 100. SE-118 60 Stockholm 

Vx: +46 8 691 49 00 | Fax: +46 8 691 49 99 

Link?ping: 

Brigadgatan 14. SE-587 58 Link?ping 

Vx: +46 13 20 03 00 | Fax: +46 13 20 03 99 

Epost: info at cambio.se | Hemsida:www.cambio.se 

 



From: openEHR-implementers 
[mailto:openehr-implementers-boun...@lists.openehr.org] On Behalf Of Sam Heard
Sent: 11 March 2013 22:04
To: For openEHR technical discussions; openEHR-clinical at lists.openehr.org; 
openehr-implementers at lists.openehr.org
Subject: RE: Guideline Definition Language (GDL) specifications and GDL-editor 
release announcement

 



Congratulations Ring

Thanks for taking such a great leading position with openEHR, which only gets 
stronger with time.

We need to think about how to integrate this in the CKM space so the rules can 
be shared when appropriate.

Cheers Sam

Dr Sam Heard
FRACGP, MRCGP, DRCOG, FACHI
Chairman, Ocean Informatics
Chairman, openEHR Foundation
Chairman, NTGPE
+61417838808






From: Rong Chen
Sent:  ?12/?03/?2013 1:28 AM
To: openEHR-technical at lists.openehr.org; openEHR-clinical at 
lists.openehr.org; openehr-implementers at lists.openehr.org
Subject:  Guideline Definition Language (GDL) specifications and GDL-editor 
release announcement



Dear all,

 

We are pleased to announce the immediate availability of the design 
specifications of Guideline Definition Language (GDL) and its reference 
implementation under open source software licenses. GDL is formal language 
designed to express and to share Clinical Decision Support rules across 
language and technical barriers by leveraging openEHR designs. CDS rules in GDL 
format is agnostic to natural languages, reference terminologies and rules 
engine languages.

 

There are considerable synergies in the development of clinical models and CDS 
rules. Semantically well-defined clinical models can provide reliable means of 
input and output of the rules. On the other hand, experiences from CDS rules 
development can lead to improvements of the clinical models as well as 
increased motivations to adopt structured and standardized clinical models. 
Reusing existing high-quality clinical models in the form of archetypes would 
hopefully increase the productivity in authoring and maintaining clinical 
rules. 

 

Please note that GDL is still in development. We aim to submit the GDL 
specifications for review in openEHR in the near future. We look forward to the 
community?s feedback to further improve the specifications. 

 

Some important links from this release:

1.   GDL Specifications (v.90)

2.   GDL Editor

3.   GDL sample files 

4.   GDL Reference Implementation Project

 

Rong Chen

On behalf of the Informatics Team,
Cambio Healthcare Systems, Sweden

 

 

Rong Chen, MD, PhD

CMIO, Director of Health Informatics

+46 8 691 49 81 

cid:image001.png at 01CE14CE.DC7B4E10 

Cambio+ Healthcare Systems AB 

Stockholm: 

Ringv?gen 100. SE-118 60 Stockholm 

Vx: +46 8 691 49 00 | Fax: +46 8 691 49 99 

Link?ping: 

Brigadgatan 14. SE-587 58 Link?ping 

Vx: +46 13 20 03 00 | Fax: +46 13 20 03 99 

Epost: info at cambio.se | Hemsida:www.cambio.se
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130312/fc14fd1c/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 146 bytes
Desc: image001.png
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130312/fc14fd1c/attachment-0001.png

Questions about commit and AUDIT_DETAILS

[Sam Heard]

Hi Pablo

Sent from my iPad

On 06/02/2013, at 7:55 AM, pablo pazos pazospablo at hotmail.com wrote:

 Hi Sam, reading more about this, it seems FEEDER_AUDIT_DETAILS is more for 
 copying stuff from non-openEHR systems,
 but from your words I tend to think it can be used also as an audit to copy 
 stuff from openEHR systems. In both cases,
 the use case for creating FEEDER_AUDIT_DETAILS might be when importing 
 records from legacy systems. Is that correct?

Yes...if you are importing complete compositions from another EHR system you do 
not need this as the Audit and contribution details capture all that is 
required.
 
 In the other hand, I haven't still a clear idea of what is considered the 
 *same system* or *same domain* and
 what should be the criteria to set a limit for the commit use case. As I 
 stated on my previous email (maybe it's not so clear),
 one system could be considered inside or outside the same domain of the EHR 
 Server (where stuff sould be committed),
 so the AUDIT_DETAILS.system_id could vary depending just on what I consider 
 to be on the same domain or not.

The system ID in audit details is the one that is committing the new 
composition. Simple, straight forward.

 
 BTW, I don't know if this is correct, but I consider importing or copying 
 records from another system a different use case
 than commiting compositions for record sharing. May be FEEDER_AUDIT_DETAILS 
 should be only used for copying/importing
 and AUDIT_DETAILS for committing. What do you think?

Yes, but if you look for sharing data between openEHR systems on the Wiki it 
will show how to preserve the information from the original commit.

Cheers Sam

 
 
 -- 
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 http://cabolabs.com
 
 From: sam.heard at oceaninformatics.com
 To: openehr-technical at lists.openehr.org
 Subject: RE: Questions about commit and AUDIT_DETAILS
 Date: Thu, 31 Jan 2013 10:24:27 +0930
 
 Hi Pablo
 
  
 
 One simple thing ? the FEEDER_AUDIT_DETAILS is there to let you record when 
 something in this composition came from somewhere else. The AUDIT_DETAILs are 
 what happened here. You do not need to record FEEDER_AUDIT but it can be 
 helpful. You can log it if you want but then it is not clear to others where 
 this came from.
 
  
 
 You need more technical input on the rest.
 
  
 
 Cheers, Sam
 
  
 
 From: openEHR-technical [mailto:openehr-technical-bounces at 
 lists.openehr.org] On Behalf Of pablo pazos
 Sent: Thursday, 31 January 2013 10:03 AM
 To: openeh technical
 Subject: RE: Questions about commit and AUDIT_DETAILS
 
  
 
 Hi guys, thanks fo your answers,
 
 Now it is more clear for me: what openEHR defines is an inter-system audit, 
 and what I tried to do is to have an intra-system audit (between subsystems 
 of the same system).
 
 There's only one confusion I need to clarify: isn't the FEEDER_AUDIT_DETAILS 
 designed to record information of the source for record copying between EHR 
 domains/environments? e.g. having FEEDER_AUDIT_DETAILS.system_id == system 
 where the composition was first committed. If so, why the 
 AUDIT_DETAILS.system_id is meant to record the same information? Or better 
 said, is there any difference between FEEDER_AUDIT_DETAILS.system_id and 
 AUDIT_DETAILS.system_id?
 
 The problem I see is we could use the word system for many purposes, and 
 other words like domain or environment could descrive better what is 
 inter or intra.
 In my case the EHR Server and the EMR apps are each one an independend 
 system, but together they also are a system. If the communication is intra or 
 inter system only depends of who controls each subsystem (EHR Server or the 
 EMR apps). In any case, I need to record an audit of the commit to the EHR 
 Server.
 
 Consider this:
 
 If there is a monolitic EMR App that has it's own composition repo (commits 
 data to itself), it could send a copy of the compositions to the EHR Server 
 to share the records with other systems.
 If the Org1 owns the EMR and the Org2 owns the EHR Server, then the system_id 
 == EMR, but if Org2 owns an EMR2 system that commits records to the EHR 
 Server, then for commits from EMR2 the system_id == Org2 (an environment or 
 domain id).
 Is this correct from the openEHR purpose for the AUDIT_DETAILS.system_id?
 
 
 About the question asked by Thomas, I don't think we need to record a device 
 id. In my case a client (i.e. an EMR App) is also a Client/Server system (my 
 apps are all web apps). So, we have a communication architecture like this:
 
 EHR Server (server) = EHR Server (client), EMR (server) = EMR (client)
 
 EHR Server (server): server side of the EHR Server web app
 EHR Server (client): client side of the EHR Server, where admins manage stuff 
 using a web GUI (web browser, device)
 EMR (server): server side of the EMR, storage, logic, etc.
 EMR (client): client side of the EMR, where end users inupt and visualize 
 data (web browser, device)
 =: HTTP communication (the EHR Server 

Questions about commit and AUDIT_DETAILS

[Sam Heard]

Hi Pablo

 

One simple thing ? the FEEDER_AUDIT_DETAILS is there to let you record when
something in this composition came from somewhere else. The AUDIT_DETAILs
are what happened here. You do not need to record FEEDER_AUDIT but it can be
helpful. You can log it if you want but then it is not clear to others where
this came from.

 

You need more technical input on the rest.

 

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of pablo pazos
Sent: Thursday, 31 January 2013 10:03 AM
To: openeh technical
Subject: RE: Questions about commit and AUDIT_DETAILS

 

Hi guys, thanks fo your answers,

Now it is more clear for me: what openEHR defines is an inter-system audit,
and what I tried to do is to have an intra-system audit (between subsystems
of the same system).

There's only one confusion I need to clarify: isn't the FEEDER_AUDIT_DETAILS
designed to record information of the source for record copying between EHR
domains/environments? e.g. having FEEDER_AUDIT_DETAILS.system_id == system
where the composition was first committed. If so, why the
AUDIT_DETAILS.system_id is meant to record the same information? Or better
said, is there any difference between FEEDER_AUDIT_DETAILS.system_id and
AUDIT_DETAILS.system_id?

The problem I see is we could use the word system for many purposes, and
other words like domain or environment could descrive better what is
inter or intra.
In my case the EHR Server and the EMR apps are each one an independend
system, but together they also are a system. If the communication is intra
or inter system only depends of who controls each subsystem (EHR Server or
the EMR apps). In any case, I need to record an audit of the commit to the
EHR Server.

Consider this:

*   If there is a monolitic EMR App that has it's own composition repo
(commits data to itself), it could send a copy of the compositions to the
EHR Server to share the records with other systems.
*   If the Org1 owns the EMR and the Org2 owns the EHR Server, then the
system_id == EMR, but if Org2 owns an EMR2 system that commits records to
the EHR Server, then for commits from EMR2 the system_id == Org2 (an
environment or domain id).
*   Is this correct from the openEHR purpose for the
AUDIT_DETAILS.system_id?



About the question asked by Thomas, I don't think we need to record a
device id. In my case a client (i.e. an EMR App) is also a Client/Server
system (my apps are all web apps). So, we have a communication architecture
like this:

EHR Server (server) = EHR Server (client), EMR (server) = EMR (client)

*   EHR Server (server): server side of the EHR Server web app
*   EHR Server (client): client side of the EHR Server, where admins
manage stuff using a web GUI (web browser, device)
*   EMR (server): server side of the EMR, storage, logic, etc.
*   EMR (client): client side of the EMR, where end users inupt and
visualize data (web browser, device)
*   =: HTTP communication (the EHR Server (server) has communication
with the EMR (server) for commit and query)


I don't think the EMR (client) id (the device where the end user is
accessing the EMR(server) from a browser) it's needed for audit at the
application level (maybe it's needed as a low level audit for sys admins).
In my case I need the id of the EMR (server) because it commits stuff to the
EHR Server (server), it doesn't matter if the EMR is part of the same domain
of the EHR Server or not.
Also consider that both of those XXX (server) has fixed IPs, but the EMR
(client) could run from any device, using dynamic IPs, but what is really
needed is the id of the logged user instead of the device id.

In the case above, do you think openEHR audit structures should support the
record of the EMR (server) id when commiting stuff to the server or I should
create my own audit structures to record that information?

Thanks a lot!

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
http://cabolabs.com http://cabolabs.com/es/home 

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

Questions about commit and AUDIT_DETAILS

[Sam Heard]

Hi Bert

 

I am sure the technical people will respond but it is a good question.

 

The commit time is the time that the author committed it to the system. I
believe this is usually generated on the server to ensure accuracy. When
there is a system with considerable delay between the clinician saving to
the record and the record being stored in the EHR repository, I would use
the Finish Time of the event context for the clinical commit time and leave
the commit time to show when this information became visible as part of the
health record.

 

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Bert Verhees
Sent: Wednesday, 23 January 2013 8:50 PM
To: openehr-technical at lists.openehr.org
Subject: Re: Questions about commit and AUDIT_DETAILS

 

On 01/23/2013 06:11 AM, pablo pazos wrote:

The definition of AUDIT_DETAILS.system_id is: Identity of the system where
the change was committed. Ideally this is a machine- and human-processable
identifier, but it may not be..

Let's say I have a CLIENT where COMPOSITIONS are created, and a SERVER where
COMPOSITIONS are committed by the CLIENT.

I understood this as not technically committed (that is the database-server)
but conceptually committed, and that is the machine on which the client-user
is typing/clicking. The client-user gives order to commit a dataset.

This is different if there is an automatic feed of data, in that case, the
feeder-audit is used. 

regards
Bert Verhees

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

Problem with specialization using the Archetype Editor

[Sam Heard]

Hi
To specialise in the current AE, you open the parent and then
File-specialise.
Cheers, Sam

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Peter Gummer
Sent: Friday, 11 January 2013 3:04 PM
To: For openEHR technical discussions
Subject: Re: Problem with specialization using the Archetype Editor

pablo pazos wrote:

 I think it would be better if the AE copies the parents nodes into the
specialized archetype when the AE user clicks on File  Specialize, of
course, only when the ADL version is 1.4.
 Manual copying is error prone. What do you think?


I'm not sure, but I think that when you upload a specialised archetype to
CKM it validates it against the parent. You can also use ADL Workbench to
validate it.

Nonetheless, that's a nice suggestion, Pablo. It would need to be a new menu
item, since File | Specialise already does something (i.e., it creates a
specialisation of the specialisation). Maybe File | Update Specialisation?

It would take a while to implement something like that, however, because
we'd have to make sure it handled everything properly. Even then, I'm sure
that corner cases would remain where the specialised archetypes got out of
step.

ADL 1.5 is the only real solution. I'd rather put that effort into moving to
ADL 1.5.

Peter


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

defaultValue/assumedValue in CPrimitive.

[Sam Heard]

Hi All

 

The reason we introduced the assumed value in the Observation.State was to
deal with the fact that many variables may be introduced in regard to the
state of the person when an observation is made - clothing, fasting,
post-challenge, at rest, on exertion, asleep, upright/sitting/lying etc.

 

Actually these 'state' variables are not recorded but are largely assumed to
be of a certain value. So we do not need to say that an ECG is at rest - but
we do need to say that it was an exercise ECG. The state variable for
exertion is assumed to be at rest unless stated. A blood pressure which is
stand alone is assumed to be sitting in most instances. The archetype allows
formal expression of what the relevant state variables are and what they are
assumed to be when they are missing. This is helpful for standardisation of
observations without massive data collection constraints.

 

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Ian McNicoll
Sent: Tuesday, 8 January 2013 12:57 AM
To: For openEHR technical discussions
Subject: Re: defaultValue/assumedValue in CPrimitive.

 

Hi Bert,

 

 

Assumed value: This is a statement in an archetype which asserts what should
happen if a value is missing. It can really only apply safely to an element
is Observation/State or in a Cluster archetype intended for use in  state.
Essentially this is a design-time statement of 'clinical knowledge' and
should not end up in data. Personally I don't use this very often as it can
be difficult to know when/how that knowledge can be safely applied. One
reasonable example is in OBSERVATION.body_weight.v1 where the 'State of
Clothing' has an assumed value of 'Lightly Dressed'.

 

 

Default value: Generally applied at template level as it will often differ
depending on the exact use-case. A default value does appear in  run-time
data.

 

As Thomas,says in his reply, Assumed value has rarely been used but it can
sometimes be helpful.

 

On 7 January 2013 13:52, Bert Verhees bert.verhees at rosa.nl
mailto:bert.verhees at rosa.nl  wrote:

Please can some one short explain what the difference is between
assumedValue and defaultValue in CPrimitive?

Thanks
Bert

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





 

-- 
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 mailto:ian.mcnicoll at 
oceaninformatics.com


Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation  www.openehr.org/knowledge
http://www.openehr.org/knowledge 
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care  www.phcsg.org http://www.phcsg.org 

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

csingleattribute and existence

[Sam Heard]

Hi Bert

 

I have been a little irritating about this in the past. The single attribute
could be determined by occurrences but I am not sure of the downstream
implications at this stage.

 

My interest has been in existence as a constraint. Clearly everything is
logically optional at any level if existence is to have any relevance.
Existence as a constraint is therefore binary - something is mandatory or
prohibited. I have proposed in XML that we have existence as a binary
statement 0 or 1.

 

The expression of existence is clearly a tertiary state - optional as well
as mandatory or prohibited - it is only as a constraint that it is binary.

 

Cheers, Sam

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Thomas Beale
Sent: Monday, 7 January 2013 9:57 PM
To: openehr-technical at lists.openehr.org
Subject: Re: csingleattribute and existence

 


Bert,

one very useful thing you can do is to identify guidelines for use of the
current specification. E.g. statements of the form

if existence is set on a single-valued attribute, and there is only one
child object, no occurrences should be set, since they can always be
inferred from the owning attribute's existence. 

and so on. These kind of statements I can add to the ADL 1.5 spec (which we
should treat as the usable spec these days).

thanks

- thomas

On 07/01/2013 11:21, Bert Verhees wrote:





But besides that, suppose you have a CSingleAttribute with REQUIRED set with
more CObjects as alternatives in it. 
All occurrences for the CObjects need then to be set to 0..1, every other
setting is erroneous. 
Occurrences 0..0 is useless, why define a CObject if it may never occur. 
Occurrences 1..1 is useless, why define alternative CObjects if the one
chosen is defined. 

Maybe the occurrences of CObjects should not be looked at when child of a
CSingleAttribute 


occurrences can be 1..1 if it is the only possibility. 


My statement was that it is useless, it can be possible but has no meaning.
Skipping the alternatives is more clear. 
And if there are no alternatives, setting the CSingleAttribute.existence to
REQUIRED does the same. 





occurrences can be 0..1 on two alternatives, with an additional rule that
says that either A or B must be there (thus satisfying the 1..1 in the
attribute itself) 

That is the only meaningful occurrence possible in the CObject. So if there
is only one meaningful, what is the point of making it configurable? 








- 
It is that I am looking further in the world then existing archetypes. 
We had the discussion about the tried enforcing top-down-structure of
archetypes and the consequences of this policy a few weeks ago. 


I'm not sure how this relates to the technical issue we are discussing
here...? 


It is because you advised me to use the existing OpenEHR archetypes and
Java-implementation. I indicated why I don't do that exclusively. 









I am also looking further than the existing Java-libraries, but that I will
soon announce more about this. 


I am not claiming that the current specification approach is perfect. But
the experience I know about elsewhere leads me to think it is pretty
workable; we don't seem to have any problems in most tools or libraries on
this issue. 

If there are aspects you are thinking about in some other kind of archetype,
please share it, that would help. 


No it is not perfect, and yes it is workable. My suggestions were partly
that I was not sure to understand the construct well, and partly to discuss
improvements. 

When I have other issues, I will gladly discuss them. 

Bert 

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

 

-- 




Thomas Beale
Chief Technology Officer, Ocean Informatics
http://www.oceaninformatics.com/ 

Chair Architectural Review Board,  http://www.openehr.org/ openEHR
Foundation 
Honorary Research Fellow, University College London
http://www.chime.ucl.ac.uk/  
Chartered IT Professional Fellow, BCS, British Computer Society
http://www.bcs.org.uk/  
Health IT blog http://www.wolandscat.net/  

 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130108/0cbc2e9a/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130108/0cbc2e9a/attachment-0001.jpg

Questions about the XSD-files.

[Sam Heard]

Hi Seref
Only one XSD set from openEHR. If we upgrade it has to be formal.
Cheers, Sam

On 27/11/2012 2:43 AM, Seref Arikan wrote:
 Greetings,
 Did I get this right? There are XSDs on openEHR web site. There are 
 also XSDs which are different than the first set, provided by LinkEHR.
 If these are XSDs of the published parts of the openEHR 
 specifications, such as RM or AOM, then there should only be one XSD 
 set, published by openEHR.
 If the XSDs belong to parts which are not part of the openEHR specs, 
 having more than one XSD theoretically would not hurt 
 interoperability, since they are not openEHR XSDs until they're 
 published by the foundation, but in practice, this would be a problem 
 waiting to emerge in the future.
 Am I missing something here? Multiple XSDs sounds like a big can of 
 worms to me.

 Best regards
 Seref


 On Mon, Nov 26, 2012 at 5:02 PM, Bert Verhees bert.verhees at rosa.nl 
 mailto:bert.verhees at rosa.nl wrote:

 Thanks Athanasios and Diego,

 It is easier to download then to write it myself ;-)

 But still I wonder why the OpenEHR-community is not offering these.

 cheers
 Bert




 On 11/26/2012 05:51 PM, Diego Bosc? wrote:

 Hello Bert,

 We created a XML Schema for the demographics part some time
 ago. You
 can download it from here.

 
 http://pangea.upv.es/linkehr/wp-content/uploads/2009/03/Demographics.xsd

 Regards

 2012/11/26 Bert Verhees bert.verhees at rosa.nl
 mailto:bert.verhees at rosa.nl:

 Hi,

 I was studying the OpenEHR XSD files, I found they
 validate fine against
 Saxon-EE 1.0 and 1.1

 But I have a few points which are not clear to me.

 1)
 In the Structure.xsd I find this line, I don't know why it
 is there.
 xs:element name=items type=LOCATABLE/

 I commented it out, and it still validates fine.

 2)
 There were some more things in the same file.
 There were no element-declarations to the concrete
 classes, like ITEM_TREE,
 CLUSTER, and so on.
 I would expect them because there are also archetypes in
 CKM based on these
 classes/elements and can be instantiated in XML.

 I added them, and now I can generate example XML with
 these classes as root,
 which was not possible before.

 3)
 It would be nice to have elements in the base-types XSD
 too. There is no
 need for it in the OpenEHR implementation, because they
 will never be
 root-element, but it is good to see their XML-structure
 isolated, for
 convenience.
 I will try that and see if they will be a problem.

 4)
 And the last point is, I missed the Demographics.xsd,
 although these
 RM-classes are also archetypeable and can lead too to
 XML-instances.

 Thanks
 Bert Verhees



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

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



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




 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 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/20121127/55726e6a/attachment.html

Commiting ACTIONs for the same INSTRUCTION ACTIVITY

[Sam Heard]

Hi Pablo,
You need to reversion the persistent composition without the medication in it. 
Ideally an action showing it has been ceased should be recorded in an event 
composition.
Cries that help?
Sam

Sent from my phone

On 12/09/2012, at 0:07, pablo pazos pazospablo at hotmail.com wrote:

 Hi Sam,
 
 What redundant data means in the context of persisten compositions?
 
 I.e. if I need to remove a medication from the medication list because the 
 patient no longer takes that drug, as I see it the medication is invalid (not 
 redundant) at the present moment.
 
 Please be as specific as you can, I really want to understand the difference. 
 Thanks a lot.
 
 -- 
 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, 14 Aug 2012 07:35:49 +0930
  From: sam.heard at oceaninformatics.com
  To: openehr-technical at lists.openehr.org
  Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY
  
  Hi All
  
  The openEHR specification is clear about the notion of update/versioning 
  of a composition or creating a new event. The idea of a persistent 
  composition is useful for information where new data ALWAYS makes 
  previous data redundant not incorrect at the time (such as a medication 
  list in a shared health record). This is useful for allergies and other 
  lists which have to be maintained.
  
  An event composition will relate to information at a particular time 
  which may be collected again but does not replace the previous 
  information. This is usually the case for most recordings. A new version 
  of this composition will invalidate the previous version (as key data 
  was missing or incorrect).
  
  Cheers, Sam
  
  On 10/08/2012 7:08 PM, Ian McNicoll wrote:
   How is the patient reporting back their exercise activity to the 
   clinician?
  
   I think it is better to create a new Composition for each 'patient
   report' rather than re-versioning a single Composition. The question
   then is how and, how often, the patient sends a report.
  
   As an example, let's say the patient reports weekly. In that case I
   would generate a new event Composition for each weekly report.
  
   Perhaps you could use a CLUSTER archetype to represent both
   recommended exercise, and the patient reported outcome, to be used in
   both the INSTRUCTION/ACTIVITY and in the ACTIONs. Can you gove more
   information on some of the detail of the exercise recommendations and
   the patient reports.
  
   Ian
  
  
   On 9 August 2012 19:28, pablo pazos pazospablo at hotmail.com wrote:
   Hi Ian, thanks for the input.
  
   I'm trying to do it by the book, obviously clinical input is essential 
   to
   model things :)
  
   What do you think about the ACTION to report patient activity?
  
   Should I create a new composition every time the patient report 
   something?
   or
   Should I version the same composition on every exercise report for the 
   same
   exercise program?
  
  
   At first I was thinking about having one ACTIVITY and versioning
   COMPOSITIONs to represent states, but then ISM states came into play :D
  
  
   In this scenario, I could keep exercise scheduling and activation states
   just in the app, and commit a COMPOSITION only when the exercise is
   finished, so I can interpret the COMPOSTION as a finished 
   activity/exersice
   on our openEHR repository (without putting an explicit state on the 
   ACTION
   archetype), and as you said, changing the state of the ACTIVITY as a much
   higher level by a clinician.
  
   --
   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
  
   From: Ian.McNicoll at oceaninformatics.com
   Date: Thu, 9 Aug 2012 18:45:56 +0100
   Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY
   To: openehr-technical at lists.openehr.org
   Hi Pablo,
  
   Thanks for the example. It makes more sense now, although I have to
   say that it feels to me as if you are overloading the idea of
   ACTIVITY/ACTION in this scenario. My approach would have been to
   regard the whole exercise program as a single task modelled as an
   Activity, and just to capture the patient-reported progress as part of
   the ACTION archetype, and only change state at a much higher-level i.e
   when the whole program is scheduled, starts or stops.
  
   There is nothing technically wrong with what you are suggesting, of
   course.
  
   I would be interested in other's thoughts - not sure if this is more
   appropriate for the clinical list?
  
   Ian
  
  
  
   On 9 August 2012 18:28, pablo pazos pazospablo at hotmail.com wrote:
   Yes! this is really clear and has been a great help.
  
   Thanks a lot.
  
  
   Just to give info that may help other in the future: in our case, the
   

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

[Sam Heard]

Hi Tom

I absolutely agree with your summary. Technically I think making use of 
obsolescence is the appropriate way to go in software. No competent 
vendor will put out an operating system, compiler or software that 
breaks existing tools without doing the work for them.

The point I am making is that there are now health records out there so 
we need to be absolutely clear that existing health records will work 
with changes. If we want to use upgrade scripts these need to be handled 
between releases so that the old and new work at the same time for a 
while and ensure we have planned obsolescence over a period of software 
cycles (say 3-5 years).

Cheers, Sam

On 6/09/2012 11:56 PM, Thomas Beale wrote:

 Personally I think the best way to look at this is as follows:

   * specifications will evolve, and they may include breaking changes.
 As a community we should stick to the usual rules (semver.org)
 whereby we identify releases containing breaking changes with a
 new major version
   * all releases should be published with the list of changes with
 respect to the previous release ('release notes') and a system
 impact statement as follows:
   o impact of the changes on *existing software*, including tools
 and re-usable libraries
   o impact of the changes on existing *archetypes and templates*
   o impact of these changes on *existing data*, and if
 appropriate, migration / transformation algorithms for the
 data to convert to the new form
   o impact of the changes on *existing queries*, and how they
 should be upgraded if appropriate

 Of course we will try our best to minimise such changes. But none of 
 us here are perfect, so we will never totally succeed at that. For the 
 last two items, there would preferably be software tools / scripts etc 
 available to do the work. Overall, the above should ensure existing 
 systems can be made to interoperate with newer systems. Obviously 
 since in openEHR we are somewhat obsessive about reference model 
 stability, we can hope that the impacts will not be great, and in fact 
 will be very acceptable in comparison to most changes in comparable 
 published standards or industry products.

 The implication is always there that someone starting an 
 implementation from scratch later on will build a better system. 
 That's life, and it's how the world makes progress. Someone with an 
 older system might have the annoyance of correcting existing queries 
 or whatever, but on the other hand, they will always be ahead in 
 database optimisation, application framework building and other 
 matters. That's life.

 I don't believe we can legislate on what organisations actually choose 
 to do with the specifications - in the end it will be up to them. Our 
 job is to make sure adopters can make /informed/ decisions. Our real 
 goal is to show how using the output of openEHR can actually lead to 
 better health outcomes for society.

 - thomas



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

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

What should AQL return in this case?

[Sam Heard]

Hi All

The work_flow_id of an entry provides a way to link any ENTRY with an 
INSTRUCTION. There are more complex workflow parameters possible within 
the ENTRY class that can be used if more complex issues arise.

Relating ENTRYs in a general way outside a particular application or 
repository is more difficult unless it follows the ACTION/INSTRUCTION 
model proposed in openEHR.

Just some ideas.

Cheers, Sam

On 20/08/2012 9:10 PM, Thomas Beale wrote:

 This is a good question. I wold summarise it as: how do I ensure an 
 AQL query picks up proximate rather than distant objects for a given 
 object?

 It depends on the data. If the only thing in the data that indicates 
 that INSTR Y1 is related to OBS X1 is temporal proximity, then you 
 would have to include something to do with time in the a WHERE clause. 
 Now, this might actually be ok - if you know a priori that a certain 
 pattern of Obs followed by Instr always corresponds to e.g. a 
 situation of 'lab result' followed by a new order (or whatever the 
 pattern that you are looking for), then this is safe to use.

 Normally such inferences would not be safe. So we need to think about 
 how the proximate Obs/instr pairs could be explicitly linked. In 
 openEHR/13606, this is done with LINK objects, so your query WHERE 
 clause could match Instructions that had a LINK pointing back to an 
 Obs with some kind of causal relation specified.

 Going one better means building some kind of active index in the 
 record, where DV_EHR_URIs are used to refer to pairs / groups of 
 Entries that are part of the same investigation, or whatever it might 
 be. Then to query, you would be querying that structure. There are 
 moves to standardise such structures in openEHR, but it's not there yet.

 - thomas

 On 20/08/2012 05:19, Seref Arikan wrote:
 Greetings,
 Here is the setting in which AQL is being used:
 We are interested in outcomes of a particular clinical instruction  
 in cases where a particular observation has been recorded.
 We want to get an attribute of both the observation and the and the 
 instruction from patient EHR. The patient's EHR has multiple 
 observations and instructions, as shown in the following diagram (the 
 dual line connections are from the partial graph representation 
 domain, meaning a child contained somewhere) The diagram also 
 contains the query and other details, which I'll discuss below

 Inline image 1


 The problem here is that the observation and instruction tuple can be 
 represented in 4 ways. (I hope the diagram represents why it is so) 
 Should AQL implementation return all 4? Then the consumer of the 
 result set would have to sort things out. This is similar to RDMS 
 behaviour when a select statement is issued on two tables without any 
 joins.
 I'm inclined to accept this as the expected behaviour, but I'd like 
 to hear what others think.

 (of course, adding some constraint that would enforce the instruction 
 to have a creation time later than the observation would return only 
 two tuples, but that is not the case I'm asking for)

 Best regards
 Seref*
 *



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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/4bafaabd/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 35089 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120820/4bafaabd/attachment-0001.png

HTML 5 Microdata

[Sam Heard]

Dear All

I am interested in how we might work from a template or data instance to 
HTML 5 microdata. There is an introduction here for people who are not 
familiar.

http://www.webmonkey.com/2010/09/microdata-html5s-best-kept-secret/

What is obvious is that standardisation of information at the 
Microformat leve will be useful for APIs that do very common things 
and being able to express these within an HTML 5 blob will be useful.

I think it might mean having a dictionary as part of CKM which respects 
the dependencies but provides key information sets for things like 
Allergies, Medications, Problems, Vaccinations, Weights, heights, blood 
pressures, temperatures etc.

Interested in what others think.

Cheers, Sam

-- 


*Dr Sam Heard*
/Chief Executive Officer/
Director, /open/EHR Foundation
Senior Visiting Research Fellow, University College London

214 Victoria Avenue
Chatswood, NSW, 2067
Phone: +61 2 9415 4994
Mobile: +61 4 1783 8808



21 Chester Cres
London E8 2PH
Phone: +44 20 7249 7085
Mobile: +44 74 2641 9957

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/b268c397/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/b268c397/attachment.jpe

Commiting ACTIONs for the same INSTRUCTION ACTIVITY

[Sam Heard]

Hi All

The openEHR specification is clear about the notion of update/versioning 
of a composition or creating a new event. The idea of a persistent 
composition is useful for information where new data ALWAYS makes 
previous data redundant not incorrect at the time (such as a medication 
list in a shared health record). This is useful for allergies and other 
lists which have to be maintained.

An event composition will relate to information at a particular time 
which may be collected again but does not replace the previous 
information. This is usually the case for most recordings. A new version 
of this composition will invalidate the previous version (as key data 
was missing or incorrect).

Cheers, Sam

On 10/08/2012 7:08 PM, Ian McNicoll wrote:
 How is the patient reporting back their exercise activity to the clinician?

 I think it is better to create a new Composition for each 'patient
 report' rather than re-versioning a single Composition. The question
 then is how and, how often, the patient sends a report.

 As an example, let's say the patient reports weekly. In that case I
 would generate a new event Composition for each weekly report.

 Perhaps you could use a CLUSTER archetype to represent both
 recommended exercise, and the patient reported outcome, to be used in
 both the INSTRUCTION/ACTIVITY and in the ACTIONs. Can you gove more
 information on some of the detail of the exercise recommendations and
 the patient reports.

 Ian


 On 9 August 2012 19:28, pablo pazos pazospablo at hotmail.com wrote:
 Hi Ian, thanks for the input.

 I'm trying to do it by the book, obviously clinical input is essential to
 model things :)

 What do you think about the ACTION to report patient activity?

 Should I create a new composition every time the patient report something?
 or
 Should I version the same composition on every exercise report for the same
 exercise program?


 At first I was thinking about having one ACTIVITY and versioning
 COMPOSITIONs to represent states, but then ISM states came into play :D


 In this scenario, I could keep exercise scheduling and activation states
 just in the app, and commit a COMPOSITION only when the exercise is
 finished, so I can interpret the COMPOSTION as a finished activity/exersice
 on our openEHR repository (without putting an explicit state on the ACTION
 archetype), and as you said, changing the state of the ACTIVITY as a much
 higher level by a clinician.

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

 From: Ian.McNicoll at oceaninformatics.com
 Date: Thu, 9 Aug 2012 18:45:56 +0100
 Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY
 To: openehr-technical at lists.openehr.org
 Hi Pablo,

 Thanks for the example. It makes more sense now, although I have to
 say that it feels to me as if you are overloading the idea of
 ACTIVITY/ACTION in this scenario. My approach would have been to
 regard the whole exercise program as a single task modelled as an
 Activity, and just to capture the patient-reported progress as part of
 the ACTION archetype, and only change state at a much higher-level i.e
 when the whole program is scheduled, starts or stops.

 There is nothing technically wrong with what you are suggesting, of
 course.

 I would be interested in other's thoughts - not sure if this is more
 appropriate for the clinical list?

 Ian



 On 9 August 2012 18:28, pablo pazos pazospablo at hotmail.com wrote:
 Yes! this is really clear and has been a great help.

 Thanks a lot.


 Just to give info that may help other in the future: in our case, the
 instruction is a recommendation to do some exercise, and we need to know
 if
 the activity (the exercise) is completed. We consider a completed
 activity
 to be one exercise instance, e.g. one walk in the park. But the
 recommendation is something like walk 30 min/day for 2 weeks, so I
 think a
 good approach is to create one ACTIVITY for each day, and let the
 patient
 change the state of each day's ACTIVITY (scheduled, started, completed).

 In this case, if the day passes and the activity was never active,
 we'll
 mark it as expired.

 Of course, any comments about this scenario are very welcome.

 --
 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, 9 Aug 2012 18:07:31 +0100

 From: thomas.beale at oceaninformatics.com
 To: openehr-technical at lists.openehr.org
 Subject: Re: Commiting ACTIONs for the same INSTRUCTION ACTIVITY

 On 09/08/2012 17:44, pablo pazos wrote:

 Hi Thomas,

 I agree with that, but I think we are talking about different scenarios.
 I
 understand we can have various ACTIONs for active states (and
 reschedule
 or suspend/resume transitions).

 My question 

Triggering behaviour

[Sam Heard]

Hi Isaac

Just saw your post. The triggering rules could be based on the reference 
model alone but would be largely to do with access notification or the 
like - e.g. if the same user saves or reads more than 20 EHRs in an hour 
to stop the user access. All clinically oriented business rules need to 
be based on AQL and DO need to know what archetypes are involved - but 
not at the time of creating the system. These rules can be written when 
and as needed.

Cheers, Sam

On 14/08/2012 4:25 PM, Isaac Lamb wrote:

 Hi All,

 I have a question regarding triggering behaviour based on data 
 captured via archetypes / templates.

 In the openEHR Architecture Overview document, the following extract 
 seems to indicate this has been considered in the openEHR specification.

 Clearly applications cannot always be totally generic (although many 
 data capture and viewing applications are); decision support, 
 administrative, scheduling and many other applications still require 
 custom  engineering. However, all such applications can now rely on an 
 archetype- and template driven computing platform.

 When developing an openEHR system, how can decision support and the 
 other actions mentioned above be implemented when there is no way to 
 know which archetypes / templates will be used in the final system?

 Kind Regards,

 Isaac Lamb

 Software Developer

 *Email*isaac.lamb at charmhealth.com.au 
 mailto:paul.smith at charmhealth.com.au?subject=Email%20Paul%20Smith

 Description: Description: Description: cid:image002.jpg at 01C8F3D1.27611F50

 Suite 13, 65 MacGregor Terrace Bardon QLD **

 *Telephone*+61 (0) 7 3512 5300 | *Fax* +61 (0) 7 3512 5399

 *Helpdesk*1300 736 320 | support at charmhealth.com.au 
 mailto:support at charmhealth.com.au?subject=Help%20Desk

 *Web*www.charmhealth.com.au http://www.charmhealth.com.au/**



   


 DISCLAIMER: This e-mail, together with any attachments, is 
 confidential and intended for the named
 recipient(s) only. If you are not the intended recipient or have 
 received this message in error, you are
 asked to immediately notify the sender and delete this message and any 
 copies of this message from
 your computer system network and destroy any printed copies of this 
 email. Any form of unauthorised
 disclosure, modification, distribution, publication or use of this 
 e-mail message is prohibited.



 Scanned by the Netbox from Netbox Blue http://netboxblue.com/


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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/c90a1392/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 168 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/c90a1392/attachment.png
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 2105 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120814/c90a1392/attachment.jpe

Questions about the relationship between Instruction, workflow and Action

[Sam Heard]

Hi Pablo,

Comments in line

Sent from my phone

On 01/08/2012, at 15:39, pablo pazos pazospablo at hotmail.com wrote:

 Hi Sam,
 
 I'm reviving this thread :D 
 
 I'm working on a project and we need to define a simple state machine, this 
 is the way I think it should be done and it would be very nice to have you 
 comments about this:

The idea is that the 'computational' state machine is defined in the RM - 
initial, active, etc. you are defining the clinically relevant steps, linked to 
this underlying state machine. These are archetyped.

 
 The idea is to record physical activity recomended by a clinician.
 
 There is one INSTRUCTION (the recommendation) with many ACTIVITIES (each one 
 a recommended sport or activity).
 We have 4 states: INITIAL, SCHEDULED, ACTIVE and COMPLETED.
 And there are 2 ACTIONS, one to record the scheduling of the activity and 
 other to record the initiation and end of the activity. (Let's say these are 
 SCHED_ACTION and INIT_END_ACTION).
 
 When a recommendation is created (INSTRUCTION and ACITIVITIES), the current 
 state is INITIAL (that should be saved on the repository that you mentioned 
 in your email).

The action will be to 'prescribe' the exercise or plan it - something the 
clinician will understand. The state will be initial.

 
 Now we need to model the state machine: INITIAL --(schedule)-- SCHEDULED 
 --(start)-- ACTIVE --(finish)-- COMPLETED.

The ACTION to schedule will have the state Scheduled, to undertake the exercise 
with state Active and then an Action to record completing the exercise with 
state Completed.

 So, we create a ISM_TRANSITION on the SCHED_ACTION with current_state = 
 INITIAL and careflow_step = schedule.

State = Scheduled

 And in the INIT_END_ACTION we have 2 ISM_TRANSITIONs with curr_state = 
 SHCEDULED and careflow_step = start,

The state is Active , the crr_state is the state after the transition.

 and the other, curr_state = ACTIVE and careflow_step = finish.

Completed

 
 The third part should be to provide the entry point to execute that ISM, so 
 we set the SCHED_ACTION.archetypeId to each ACTIVITY.action_archetype_id, so 
 when the INSTRUCTION is on INITIAL, only a SCHED_ACTION could be executed.
 
 And, on any ACTION execution, we update the repository with the action 
 executed and the new state (and we keep all the actions and transitions taken 
 so we can reproduce the process later).
 

This is correctlinking with EHR path or WorkflowID - which allows linking 
other ENTRYs as well.

 
 What do you think? That's the right way to do it?
 

Hope that helps - Sistine might give a little more guidance.

Cheers Sam

 -- 
 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
 
 From: sam.heard at oceaninformatics.com
 To: openehr-technical at openehr.org
 Subject: RE: Questions about the relationship between Instruction,
 workflowand Action
 Date: Wed, 7 Dec 2011 13:09:31 +0930
 
 Hi Pablo,
 
  
 
 The design principles are that the Instruction should remain unaltered by 
 people basing actions on this instructions ? as the action and instructions 
 could be disconnected at any moment. For example, the instruction (medication 
 order) should not be changed by anyone just to give a medication etc.
 
  
 
 So the state of the instruction is carried in the record of the action (if 
 appropriate). We have decided to name the pathway steps and attach a machine 
 readable state to that step. This makes it much easier for clinicians to 
 model and to see what is going on.
 
  
 
 In our openEHR repository we maintain an instruction index ? that is a 
 pointer to all instructions and all actions that relate to that instruction ? 
 and the current state of the instruction.
 
  
 
 You will see an archetype ACTION in the openEHR repository and the 
 careflow_steps are archetyped to provide a name and the current state matches 
 an openEHR code for state. This means that a careflow step being carried out 
 will set the state to a particular machine state.
 
  
 
 Hope this helps.
 
  
 
 Cheers, Sam
 
 
 
 From: pazospablo at hotmail.com
 To: openehr-clinical at openehr.org; openehr-technical at openehr.org
 Subject: Questions about the relationship between Instruction, workflow and 
 Action
 Date: Sun, 4 Dec 2011 15:36:36 -0300
 
 Hi everyone!
 
  
 
 I'm trying to understand how to execute a state machine of a fully structured 
 INSTRUCTION, and I have some questions and thoughts to share with you...
 
  
 
 The first issue is about archetyping an ACTION that execute and ACTIVITY of 
 an INSTRUCTION. Modeling an ACTION, the Archetype Editor let me archetype the 
 ACTION.ism_transition attribute, but not the ACTION.instruction_details. Both 
 attribute classes (ISM_TRANSITION and INSTRUCTION_DETAILS) are 
 specializations of PATHABLE, so those shouldn't be archetypable (see 
 

HL7 ANY type

[Sam Heard]

HI Bert
Heath is away but he will share with you that we have been taking the 
same approach. LOINC codes or name values are the basis for our queries 
when there is no specific archetype. So we have the path to the values, 
but use the names of the elements for queries.
Cheers, Sam

On 10/07/2012 8:19 AM, Thomas Beale wrote:
 On 09/07/2012 22:41, Bert Verhees wrote:
 Op 09-07-2012 17:15, Seref Arikan schreef:
 implementation, that would be a big set of data, which you'd have to 
 downcast in your own implementation and apply filters.. Would you 
 like to discuss your use case in more detail? 
 Hi Seref,

 Thanks for your interest.

 The use case is about, that we need to write a set of archetypes 
 which is usable as datastorage for a HL7 VMR-model in a 
 decision-system. In this model, there is an ObservationResult with 
 type ANY to hold the observation-value.
 The only query-able solution we can find is to specialize the 
 archetype to common situations. We have, for example an 
 ObservationResult related to pregnancy, in a specialized archetype.
 Depending on the kind of DataValue, there are other attributes.

 Hi Bert,

 well, the whole idea of archetypes is that you know what particular 
 data configurations are actually being created, out of the billions of 
 ones possible from the statically declared information model. With no 
 archetypes, then you just have the information model, and you can 
 query on that, but you have no idea what you are going to pick up 
 because you don't know what your data are. But nothing technically 
 prevents you from putting in paths that assume e.g. 
 ObservationResult.value is a PQ, i.e. .../value/units or whatever it 
 comes out to be.


 The customers/users, however are not happy with this. They wonder how 
 it is be done in HL7, of they have the same problem. I don't know, 
 does someone know?

 there's no problem here - it is how any information system works - if 
 there are no archetypes, you just end up querying on the static 
 information model and hope for the best.


 What would be a good solution, it would be good also if AQL had a 
 solution to query the type of a datavalue, and than it would be 
 possible to query the value, depending on the type, there would be 
 another attribute to query.

 at the moment this would not generally be possible, because it would 
 rely on the concrete persisted form of the objects including their 
 data type (i.e. 'class name'). The openEHR RM doesn't mandate this, 
 although someone might add it to there private persistence solution. 
 If it were there e.g. if  you added an attribute to LOCATABLE like 
 rm_type: String and then query on that.

 Why not just use archetypes and templates? This achieves the same 
 result in a better way. Even if your archetypes are generic for 
 attributes like the above one, obviously some particular data type was 
 chosen at run time. You can include in your archetype all sensible 
 alternatives for the attribute in question, each with its own at-code. 
 Then when the data are stored, they will have the at-code of the 
 actual archetype node used, i.e. the TS or PQ node or whatever. That 
 means you can build an AQL query for exactly that data object.

 - thomas


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

SMART platform and RDF

[Sam Heard]

Hi Kathrin

This is very exciting news and I look forward to catching up on this 
area. It has been attempted on a few occasions, I believe as the OWL 
tooling improves we are likely to see benefits.

Cheers, Sam

On 3/07/2012 8:29 PM, Kathrin Dentler wrote:
 Dear all,

 Here in Amsterdam we are working on expressing archetypes as OWL 
 graphs, and actually I think that it would be ideal to host them under 
 the openEHR domain in future.

 We transform archetypes from ADL to OWL, with the work of Catalina 
 Costa from Medical University of Graz (previously in Universidad de 
 Murcia) and Leonardo Lezcano from the Universidad de Alcal? as a 
 starting point. Please consult our paper [1] that has been accepted 
 for the KR4HC workshop for details. It is not yet camera ready, but it 
 gives an overview of some advantages of representing archetypes in OWL.

 Currently Alberto Maldonado from IBIME, Technical University of 
 Valencia, is doing a research visit in our group. He is working on 
 generating OWL data (individuals) that are compliant with the OWL 
 representation of archetypes from both legacy XML data and archetype 
 compliant XML EHR extracts. The idea is to have normalized clinical 
 data expressed in OWL in order to ease its reuse in clinical research 
 (mainly clinical trials) and quality measurement.

 Best regards,
 Kathrin Dentler

 [1] http://www.few.vu.nl/~kdr250/prohealth12kr4hc_archetypes_owl.pdf



 Op 03-07-12 10:19, Ian McNicoll schreef:
 There is quite a bit of interest in the UK in adapting the US-based
 SMART platform www.smartplatforms.org for UK use. One aspect of SMART
 involves the definition of a fairly simple API which serves RDF graphs
 of archetype like objects e.g Blood pressure, allergy. The SMART guys
 are aware of openEHR and have been quite support of it in the CIMI
 work, and I understand that they do not see the clinical content
 definitions underpinning the APIs as core business.

 It seems to me that there is an interesting possibility of using
 openEHR archetypes (probably templated) to define the clinical content
 which is to be expressed as RDF graphs. This will give a much more
 adaptable and extensible approach + better model governance etc.

 It seems to me that the key requirement is to be able to create a
 run-time artefact, in the same way that we create Template data schema
 but to output RDF rather than XSD. Is this correct and if so, does
 anyone have any experience with this?

 The other interesting aspect is that because the SMART API returns
 mostly ENTRY-level components, these need to be wrapped in some
 COMPOSITION level metadata. Does it make sense that we actually return
 very lean EHR Extracts?

 Ian

Regarding the role of ITEM_STRUCTURE

[Sam Heard]

Hi Anthanasios

I think time has shown that this is probably an area of over engineering 
in openEHR. All archetypes are now ITEM_TREE and could be clusters.

If we think of these as providing constraint on an underlying cluster - 
ITEM_LIST is a cluster of ELEMENTs and ITEM_TABLE sets up a set of 
clusters to provide the Information structure of an addressable table.

There is a place for ITEM_LIST and ITEM_TABLE but the other issue is 
these constraints might be brought to bear at any point in an 
information hierarchy.

I have proposed in version 2 of the RM that we make these 
specialisations of CLUSTER as a constraint statement. That would ensure 
backward compatibility.

Cheers, Sam

On 16/06/2012 1:25 AM, Athanasios Anastasiou wrote:
 Hello everyone

 I am sending this email to clarify the role of ITEM_STRUCTURE in
 relation to other structures (such as HISTORY and EVENT) both from the
 point of view of EHR semantics as well as the computational view.

 My problem in one line is that i can't understand if ITEM_STRUCTURE
 are there to ensure that their content is interpreted properly
 semantically or they really do what they mean (i.e. they represent
 tables, lists, trees that have to be populated as such).

 A related question is also this one:

 Is it possible that a C_MULTIPLE_ATTRIBUTE constraint pointing to an
 ITEM_LIST will have upper_unbounded=True?

 If yes, then ITEM_LIST would have to be dynamically expanding (and this
 complicates things a little bit but...that's life)...If no, then the
 contents of ITEM_LIST can be considered static (yay!) and you only need
 to know that this is an ITEM_LIST for interpretation purposes (which of
 course is KEY when you come across an ITEM_TREE)

 This will help me in two points:
 a) Clarify the role of ITEM_STRUCTURE and use it properly in archetypes
 and templates
 b) Be able to assign widgets properly (and later read data off them)
 when constructing a GUI.

 A few more notes are available at the end of this message

 All the best
 Athanasios Anastasiou



 What i understand but would like to verify is that ITEM_STRUCTURE do
 what they say they do, i.e an ITEM_LIST represents a dynamic list
 (constrained by some C_MULTIPLE_ATTRIBUTE) and an ITEM_SINGLE
 representsjust one entry (constrained by some C_SINGLE_ATTRIBUTE).

 But i am a little bit confused for two reasons:

 a) by what is meant by HISTORYT.

 HISTORY already implies A list of events with the type of the list
 being (point or interval)EVENTT which could imply A [single item or
 table] of ITEM_STRUCTURE OR A [list,tree] of ITEM_STRUCTUREand
 this is where it gets confusing.

 Does that mean that all of the following are valid? (with respect to
 HISTORYT)

 *) a dynamic list of events containing dynamic lists of item structure
 (the history.events can expand and so can the item structures held by
 events)

 *N1) a dynamic list of events containing static lists of item structure
 (events can expand, but each event is supposed to simply contain a list
 of items that is actually fixed in size).

 (dynamic and static expanded for the following lines as well)
 *) A list of trees
 *) a list of tables
 *) a list of single values (this is the most intuitive thingFor
 example, a time series represented as a history of point events of
 single_value...)


 b) by the explanation given in the specs
 With reference to (*N1) above:
 The example that is given in the spec for ITEM_LIST is that of parts of
 an address. This is what leads me to believe that ITEM_LIST is not
 supposed to be a dynamic list but just something THAT IS TO BE
 INTERPRETED AS A LIST but from a computational point of view is just a
 list. I really do hope this makes sense. (I have gone through section 6
 in data_structures.pdf and that again points to ITEM_STRUCTURE being
 used for interpretation rather than definition :-/)

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

13606 revisited - list proposal

[Sam Heard]

Hi Graham

 

The summary of the time series can be as structured as you like. No limit ? 
just archetypes. The fact that the first requirement you expressed was a 
graphic as part of the report, but it has never been archetyped.

 

Protocol began as there is a lot of data about how information is captured that 
is of secondary importance. This does not mean it is not important to some key 
users. The good part about having this set of data is that it can be agreed 
that by clinicians that they do not want this data ?in their face? when looking 
at the EHR. This means that there can be a generic display archetype for the 
different entries that can group this data and make it available through a 
click, mouse over or whatever. It is pragmatic in a world where we start to 
share structured data that is not known to a particular system (at least not 
until a later release.)

 

Cheers, Sam

 

From: openehr-technical-bounces at lists.openehr.org 
[mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Grahame Grieve
Sent: Tuesday, 27 March 2012 5:24 AM
To: For openEHR technical discussions
Cc: openehr-technical at lists.openehr.org
Subject: Re: 13606 revisited - list proposal

 

Hi. 

 

Several comments:

 

 We put it in because Grahame Grieve had identified a use case where there was 
something like an image that summarised the data in the time series in some 
visual way. 


Right. But had I know then what I know now, I would've held out for a less 
limited summary that could contain structured data summarization of the series.

 

Protocol' has a clear purpose and gets used for that purpose as far as I can 
see in most archetypes: it contains the method of performing Observation / 
Evaluation / Instruction etc





Umm, but how do you handle the situation where data produced by the observation 
is structurally related to the protocol? The NEHTA pathology and radiology 
archetypes have data in the protocol for this reason.







The question of display I don't see as important

the minute we start sliding toward undisciplined data models, we start heading 
back toward the non-computable data we have today





Really? Because we know better than the people who collect and use their data 
what they need? I think that sometimes we actually do, but nevertheless this is 
very slippery ground. There's a reason why we have what we have today. As for 
display, data is no good unless it is displayed...



 

Grahame


On 27/03/2012, at 1:23 AM, Thomas Beale thomas.beale at oceaninformatics.com 
wrote:



Indeed we had something like this in Release 0.95 of openEHR 
http://www.openehr.org/releases/0.95/roadmap.html  - see from the old spec 
http://www.openehr.org/releases/0.95/architecture/rm/data_structures_im.pdf . 
This HISTORY model worked badly for multi-valued data. 

ebgbhgab.png


However, if we are going to make a change, I think the correct model is not 
just to add a different variant of HISTORY but a different variant of 
OBSERVATION, with a single EVENT. This might be called SINGLE_OBSERVATION or 
similar. Note that the EVENT could still be a POINT_EVENT or an INTERVAL_EVENT. 

The reason we defined the current model with the time-series is that it means 
software is simpler: there is only one model of all Historical (i.e. 
observation) data: a History of Events. If we make the change we are talking 
about here, the software becomes more complicated, and the data become more 
varied, but overall, smaller. Also, archetype modellers might see the choice of 
an explicit SINGLE_OBSERVATION as being more obvious for some Observation types 
(tools should have supported this anyway from day 1, and just built a normal 
OBSERVATION, but this wasn't done)

So what we are talking about are essentially differing optimisations - greater 
software complexity, greater data variation, smaller data versus simpler 
software but (slightly) less space-efficient data,. I personally don't mind too 
much which way we go here - adding a single-event OBSERVATION type will fit 
well in the 'clinical investigator model' ontology which underpins the openEHR 
Entries. Many archetypes, including all patient story  POMR 'subjective' 
Observations are of the single-event type.

I don't think we should be pulling apart the rest of the model semantics though 
(lower data structures are a different matter; see my other posts). 'Protocol' 
has a clear purpose and gets used for that purpose as far as I can see in most 
archetypes: it contains the method of performing Observation / Evaluation / 
Instruction etc. If this is not being done, there is a problem in the 
modelling. The question of display I don't see as important. What is important 
is that protocol doesn't change the meaning of the data+state in any routine 
data situation (e.g. just show me all the arterial BPs) . It can be ignored for 
normal computing purposes. However, for purposes relating to the method itself 
(e.g. should we measure BP on both arms to 

Archetype authoring attribution

[Sam Heard]

Hi David

 

As the aim for all is interoperability of these things, I would hope that
the information would be two way. I would suggest getting the new experts to
comment on CKM and then derive a 13606 archetype (this is described in the
13606 standard). I would like that to be a future part of CKM but understand
this may seem a little too controlling.

 

If we start creating clinical content specifications in lots of places it
will not really assist medicine a great deal. We estimate that it is costing
health care dearly to do this again, again and again. Particularly when
providers are interested in quality and sharing information.

 

That said, I would attribute the work to openEHR, the original authors,
contributors and any new expert inputs. The license is to openEHR so I guess
it is openEHR that needs attributing if you want to stay with the legal
requirement. The SA does mean that you have to share the derived work under
a similar license, something that some have been worried about. I am
interested in your views on this.

 

Cheers, Sam

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of David
Moner
Sent: Thursday, 22 March 2012 9:33 PM
To: OpenEHR clinical discussions; OpenEHR technical discussions
Subject: Archetype authoring attribution

 




Hello,

 

Back again with the licensing topic of archetypes, with a real use case.

 

We have been asked to help in creating a set of 13606 archetypes for breast
and prostate cancer. Although they will probably incorporate some new
requirements, the main source will be some of the openEHR archetypes
available at the CKM.

Assuming that the have adopted a CC-BY(-SA) license (I cannot recall which
is the state of that discussion), the doubts are the following:

 

- Converting the archetype to a new reference model is considered as a
derivation? Or the openEHR archetype is considered just as a reference
material as could be any textbook or paper?

- The author of the new archetype has to be the one of the openEHR archetype
(Ian McNicoll btw) or the person who in fact creates the new RM-based
archetype?

 

The underlying question here that should be clarified is to define which is
the extension of the concept derived work.

 

David

 

-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)

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

Units, Quantities, etc

[Sam Heard]

Hi All,

I think the units database that we have as part of openEHR tooling allows
for the addition of equivalent and language dependent expressions, as well
as conversion where that is possible.

How about we make that available somewhere to get this going. It does mean
we are not beholden to others and can know when we have UCUM compatible
expressions (convert if necessary).

Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
 technical-bounces at lists.openehr.org] On Behalf Of Thomas Beale
 Sent: Wednesday, 21 March 2012 11:15 PM
 To: openehr-technical at lists.openehr.org
 Subject: Re: Units, Quantities, etc
 
 On 21/03/2012 09:28, Grahame Grieve wrote:
  But the question around can you trust the data is, can you recognize
  properly when the units are ucum or not? For some reason I haven't
 put
  my finger on, you are linking the knowing of this with the boundary
 of
  the type. It's not clear to me why you're making that link.
 
  Grahame
 
 
 well... good question. So in other words: if there is a units field
 specifically for 'formal' units, is it UCUM only or not? I would have
 said it should be except for annoying problems like the one Heath
 mentioned - UCUM uses '*' for exponent instead of '^' which almost
 everyone else uses
 
 We could use the same approach as an openEHR DV_PARSABLE, where the
 name of the syntax is stored as well, but this is IMO inviting a
 different kind of pain...
 
 My answer would be: let's get UCUM doing everything we need (for the
 formal units field I mean, not the informal one); if we can't, we need
 a new UCUM.
 
 - thomas
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-
 technical_lists.openehr.org

openEHR / FHIR data types cross analysis

[Sam Heard]

Sorry about the XML slur :) Sam

 -Original Message-
 From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
 technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve
 Sent: Monday, 19 March 2012 8:16 AM
 To: For openEHR technical discussions
 Subject: Re: openEHR / FHIR data types cross analysis
 
 Hi Sam
 
 Actually, this has come up in a couple of other places. The FHIR data
 types are defined for use within the FHIR framework. There's two very
 important parts of FHIR that influence the modeling of the data types:
 * the FHIR take on extensibility
 * the fact that all FHIR resources have a narrative section It's become
 clear to me that this will mean that the FHIR data types aren't
 suitable for use elsewhere
 
 More generally, I don't think you can define a set of data types
 independently of a set of framework assumptions - and therefore data
 types are only independent of reference models if said reference models
 share the same framework assumptions.
 
 But I'm quite offended by the notion that I'm influenced by XML.
 Bah. Might as well have said that I'm influenced by text.
 Actually, like Thomas, I prefer to work in a 3gl framework ;-)
 
 Grahame
 
 
 On Mon, Mar 19, 2012 at 8:00 AM, Sam Heard
 sam.heard at oceaninformatics.com wrote:
  Hi
 
  This is an interesting discussion. It seems that we might have hit
 the
  issue of defining data types independent of a reference model. In a
  reference model we do want to know that there are a limited set of
  types (formally
  expressed) that can be used at any point.
 
  I was influenced by the discussion at CIMI that demonstrated this.
 
  So the sort of textural elements you have within the datatypes that
  allow someone to say Autumn for datetime (HumanDate) are probably
 best
  dealt with in models where that is appropriate and with a suitable
 set
  of terminologies.
 
  An uncertain datetime is better for processing than a text (soon
 after
  my mother died). There is no doubt about the usefulness of the text,
  just that it does not belong in a date field.
 
  The FHIR may be suitable for messages at this point in time, if so,
 it
  is easy to port information to this.
 
  Let's keep this thread alive and get a little broader input. Thomas
 is
  influenced by Eiffel, Grahame by XML. Most developers will probably
  sit somewhere in between in terms of requirements for rigor.
 
  Cheers, Sam
 
 
  -Original Message-
  From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
  technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve
  Sent: Sunday, 18 March 2012 11:50 PM
  To: For openEHR technical discussions
  Subject: Re: openEHR / FHIR data types cross analysis
 
   I just wasn't thinking what I wrote this. In FHIR, a boolean data
   type, primitive, is a type that can be used in models an is
   exactly equivalent to DV_BOOLEAN.
  
   but isn't the problem that it doesn't inherit from some DATA_VALUE
   parent type (Any in HL7 data types)? How can it be one of the
  possible
   values in a location like ELEMENT.value which would be statically
   typed to this parent type (as it is in 13606, HL7 RIM and openEHR)
   unless it is a descendant of this type?
 
  FHIR has no such restriction - elements must have a type of one or
  more of the defined types, either primitive or complex
 
   Well, this is the HL7 modelling mentality, trying to create a
   data type class with all possible attributes, some of which can
   be removed in some subclass.
  
   not at all. nothing is removed in FHIR. There are some data types
   where attributes in the superclass are constrained by the
  definitions
   in the subclass.
   You do the same.
  
   do we?
 
  yes, check out DV_EHR_URI - this is exactly the same pattern for
  exactly the same reason
 
   does anyone use the Java.util calendar type? It's hopeless for
   dates and times!
 
  I use java.util.Date. don't know anything about calendar. but so
 what.
 
   I think it is mostly the latter - Date is usually used when time
   info is really not of interest or expected.
 
  why shouldn't the relationship between date and datetime be the same
  as that between DV_EHR_URI and DV_URI? I haven't defined that, but
  that would be the natural way to do it in FHIR.
 
   I want a spec that looks like an openEHR spec ;-) That's
 useful
 
  I don't think I'll do exactly like (framemaker!), but others have
  asked for a formal computable statement of constraints.
 
   Should I do anything about them, or are they just there because
   they were thinking of straight text? Do they think
  formatting/hyperlinking
   is important?
  
   that can be constrained in the archetype as well.
 
  but it generally isn't - and can't be in the archetype builder.
  So I don't know what was intended.
 
   DV_TEXT is a text, optionally with mappings. DV_CODED_TEXT
   elevates one of the mappings to being defining.
  
   well 'defining_code' isn't a mapping

openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Sam Heard]

Hi Shinji

We could not get sponsorship for the conference, which is a shame. For that
reason it looks like that will not happen until we have Associates and some
core funding.

I would like to organise some Google handouts at different times each month
- probably 3/month suiting Asia, Europe/Africa and the Americas. Would
others be interested in meeting for a chat every month, with Video. We could
use GoToWebinar for some more formal gatherings.

Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
 technical-bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI
 Sent: Friday, 2 March 2012 10:40 AM
 To: For openEHR technical discussions
 Subject: Re: openEHR conference - proposal for Lake Bled, Slovenia 2012
 - POLL
 
 Hi all,
 
 Can I resume this topic?
 I am much looking forward to meeting this conference.
 I know there are many problems, but just to do it very great for us.
 
 Regards,
 Shinji
 
 2012/1/13 Thomas Beale thomas.beale at oceaninformatics.com:
  On 13/01/2012 08:14, Ian McNicoll wrote:
  I do like the idea but I would prefer that each conference has its
  own very clear identity, albeit that some sessions could be shared,
  along with venue etc. A couple of the MIE conferences have operated
  this way with local informatics conferences being co-hosted/located
  with the European event, with some joint sessions but otherwise a
  very clear individual agenda and focus.
 
 
  Right - that could be a solution.
 
  - thomas
 
  ___
  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 lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-
 technical_lists.openehr.org

openEHR conference - proposal for Lake Bled, Slovenia 2012 - POLL

[Sam Heard]

Hi Shinji

We could not get sponsorship for the conference, which is a shame. For that
reason it looks like that will not happen until we have Associates and some
core funding.

I would like to organise some Google handouts at different times each month
- probably 3/month suiting Asia, Europe/Africa and the Americas. Would
others be interested in meeting for a chat every month, with Video. We could
use GoToWebinar for some more formal gatherings.

Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
 technical-bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI
 Sent: Friday, 2 March 2012 10:40 AM
 To: For openEHR technical discussions
 Subject: Re: openEHR conference - proposal for Lake Bled, Slovenia 2012
 - POLL
 
 Hi all,
 
 Can I resume this topic?
 I am much looking forward to meeting this conference.
 I know there are many problems, but just to do it very great for us.
 
 Regards,
 Shinji
 
 2012/1/13 Thomas Beale thomas.beale at oceaninformatics.com:
  On 13/01/2012 08:14, Ian McNicoll wrote:
  I do like the idea but I would prefer that each conference has its
  own very clear identity, albeit that some sessions could be shared,
  along with venue etc. A couple of the MIE conferences have operated
  this way with local informatics conferences being co-hosted/located
  with the European event, with some joint sessions but otherwise a
  very clear individual agenda and focus.
 
 
  Right - that could be a solution.
 
  - thomas
 
  ___
  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 lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-
 technical_lists.openehr.org

visualizing AQL result

[Sam Heard]

Leykun

The result of the query might be a table or some objects (as XML). The
display of these needs to use a script - which I believe is available in the
public domain. I will copy to Heath to ask about this.

Cheers, Sam

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Leykun
Melkamu
Sent: Friday, 2 March 2012 9:31 AM
To: openehr-technical at openehr.org
Subject: visualizing AQL result

 

Hello!

 

I am a student and working my thesis on openEHR application can I get help
on how to visualize the result of my AQL queries. How can I use the
operational template and the c # code generated from oceans template
designer?  Thanks in advance for your help. 

 

Best regards,

 

Leykun 

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

openEHR (local) terminologies

[Sam Heard]

Hi Diego
Rong has made this generally available - or it is in the download of the
archetype editor.
Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
 technical-bounces at lists.openehr.org] On Behalf Of Diego Bosc?
 Sent: Thursday, 1 March 2012 8:39 PM
 To: For openEHR technical discussions
 Subject: openEHR (local) terminologies
 
 I sent this email when I thought the migration process was over, but it
 wasn't. I am sending it again, sorry if someone receives two copies
 :)
 
 Is there any place where openEHR local terminology files (e.g. the
 possible values from C_DV_QUANTITY.property or
 DV_CODED_TEXT.defining_code) can be viewed? (as code/description
 tables)
 
 Regards
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-
 technical_lists.openehr.org

openEHR (local) terminologies

[Sam Heard]

Hi Diego
Rong has made this generally available - or it is in the download of the
archetype editor.
Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-
 technical-bounces at lists.openehr.org] On Behalf Of Diego Bosc?
 Sent: Thursday, 1 March 2012 8:39 PM
 To: For openEHR technical discussions
 Subject: openEHR (local) terminologies
 
 I sent this email when I thought the migration process was over, but it
 wasn't. I am sending it again, sorry if someone receives two copies
 :)
 
 Is there any place where openEHR local terminology files (e.g. the
 possible values from C_DV_QUANTITY.property or
 DV_CODED_TEXT.defining_code) can be viewed? (as code/description
 tables)
 
 Regards
 
 ___
 openEHR-technical mailing list
 openEHR-technical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-
 technical_lists.openehr.org

openEHR-technical Digest, Vol 67, Issue 34

[Sam Heard]

Hi Tim
HL7 Twittered about making things more openly available the other
daydoes anyone have the link?
Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Timothy Cook
 Sent: Thursday, 23 February 2012 4:44 AM
 To: For openEHR technical discussions
 Subject: Re: openEHR-technical Digest, Vol 67, Issue 34
 
 How can anyone say that HL7 is open in any fashion?  You are not free
 to distribute it outside of your organization except in small parts so
 that the specifications cannot reproduced.
 
 See the paragraph immediately preceding the one previously quoted here:
 
 HL7 CORPORATE/ORGANIZATIONAL MEMBERS are authorized to:
 
 reproduce and distribute Material on an internal basis solely for
 use within their organization;
 reproduce and distribute excerpts of Material (not entire domains
 or chapters) to any customers of a product or service implementing
 those Material, provided that the HL7 Access database may not be
 included, either in whole or in part, in any product intended for
 direct or indirect commercial resale;
 use excerpts of Material to create customized implementation
 guides; and
 use Material in the development of software applications and
 messaging systems for direct use or distribution without additional
 licensing fees.
 
 There is NOTHING open about this, fee paid or not.
 
 --Tim
 
 On Mon, Feb 20, 2012 at 17:55, Thomas Beale
 thomas.beale at oceaninformatics.com wrote:
  On 20/02/2012 22:34, William Goossen wrote:
 
  Hi Heath, Thomas,
 
  My experience is that HL7 v3 is an open standard and OpenEHR is
  proprietary (as owned by the OpenEHR foundation holding the
  copyrights, albeit I understand that work is underway to sort that
 out).
 
 
 
  Correction: HL7 is open, although requires a small fee for use;
  openEHR is an open and free specification. Neither are proprietary;
  proprietary essentially means 'not openly published and usable'. That
  does not apply to either HL7 or openEHR.
 
  - thomas
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
 
 
 --
 
 Timothy Cook, MSc
 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 openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR / FHIR data types cross analysis

[Sam Heard]

Sorry about the Eiffel slur J

Cheers, Sam

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas
Beale
Sent: Monday, 19 March 2012 8:18 AM
To: openehr-technical at lists.openehr.org
Subject: Re: openEHR / FHIR data types cross analysis

 


Actually, Eiffel has nothing to do with it (I wrote my own date/time
libraries based on ISO 8601 semantics). What I am influenced by is what I
see in CKM and other repositories.

openEHR CKM



NEHTA CKM


On 18/03/2012 21:00, Sam Heard wrote: 

Hi
 
This is an interesting discussion. It seems that we might have hit the issue
of defining data types independent of a reference model. In a reference
model we do want to know that there are a limited set of types (formally
expressed) that can be used at any point.
 
I was influenced by the discussion at CIMI that demonstrated this.
 
So the sort of textural elements you have within the datatypes that allow
someone to say Autumn for datetime (HumanDate) are probably best dealt with
in models where that is appropriate and with a suitable set of
terminologies.
 
An uncertain datetime is better for processing than a text (soon after my
mother died). There is no doubt about the usefulness of the text, just that
it does not belong in a date field.
 
The FHIR may be suitable for messages at this point in time, if so, it is
easy to port information to this.
 
Let's keep this thread alive and get a little broader input. Thomas is
influenced by Eiffel, Grahame by XML. Most developers will probably sit
somewhere in between in terms of requirements for rigor.
 
Cheers, Sam
 
 
 
 
 
 
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0001.html
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 21360 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0002.png
-- next part --
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 19995 bytes
Desc: not available
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/2e05a44e/attachment-0003.png

Python / Django experience??

[Sam Heard]

Hi,

 

We started archetype development in the NHS using Subversion and it got in a
real mess very quickly. As Pablo says the version and dependencies are not
the same as in code.

 

I think we need to consider what are the tools that are needed now to make
openEHR more attractive to clinical application developers, and what are the
functions of those tools. Let's ensure that businesses can thrive working in
the openEHR environment and make sure we try and fill the gaps as the first
priority.

 

Cheers, Sam

 

 

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Wednesday, 8 February 2012 4:14 AM
To: openehr technical
Subject: RE: Python / Django experience??

 

Hi Erik and all,


 On Thu, Feb 2, 2012 at 18:19, pablo pazos pazospablo at hotmail.com wrote:
  I don't know if this is crazy talk or if it's seems reasonable to you.
Please let me know :D
 
 Not crazy, but maybe overly complicated.
 

Maybe I don't present the idea in the best way, but in the end is just some
services to advertise/discover artifact repositories/servers, services to do
distributed queries, and services for notifications (subscribe/notify). Some
of this ideas are in use out there for zillions since Internet born and
evoluted.


 Perhaps it would be a good idea to use a layered approach?
 1. An existing distributed version control system (DVCS) like GIT (and
 an agreed directory structure and naming conventions within it) for
 storing versioning and distributing archetype source files etc.

About using some version control system (VCS), I don't think this is a good
solution because the semantics of archetype version are not the same
semantics as in plain text versioning (here changing one character will
create a new version of the artifact). With VCS you can handle
local/internal evolution of an archetype in development, but for a
global/public archetype versioning system, IMO this is not the right tool to
handle archetype versions (and other artifact versions).

 

I think we need to define the versioning system/semantics/context of an
artifact, and then implement this spec on design tools or in each artifact
repository. If I'm not mistaken, a discusion about this topic took place a
while ago and I don't know if there was consensus on the proposals.

 

Kind regards,

Pablo.

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

Python / Django experience??

[Sam Heard]

Hi All

 

I want to ensure that the technical possibilities do not overwhelm the
clinical reality in this space. It is a very new space and, for
interoperability and sharing of applications, we need to align ideas for
shared data specifications as part of the process. It has been and remains
attractive to consider code repository support for this activity, but I
think a much less sophisticated approach that engages leaders in an
alignment process is most important.

 

The key decision in these early days is what to put in the parent archetype
and what to keep for localisation through specialisation or templates.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Friday, 3 February 2012 2:50 AM
To: openehr technical
Subject: RE: Python / Django experience??

 

Hi all,

 

What I've been thinking is to share the same interface/protocol to do simple
tasks on distributed CKMs like:

 

1.  Adding an artifact (archetype, template, termset, terminology
service, process definition, gui template, etc.), lets think only about
archetypes for now.
2.  Updating an archetype (with version management)
3.  Listing all the archetypes
4.  Listing all the archetypes for one RM type (i.e. composition, entry,
action, etc.)
5.  Listing all the archetypes that archetype_id match a regexp
6.  Listing all the archetypes that match some text (free text search)
7.  Retrieve archetype in ADL/XML/JSON/YAML by archetype_id

 

 

Ian, about the requirements you mention:


 Basic requirements
 
 1. Query across multiple repositories using multiple criteria, based
 on something similar to the CKM ontology.

 

For this I think something like DNS protocol will do the job
(http://en.wikipedia.org/wiki/Domain_Name_System). DNS could do a
distributed search by redirecting the query if some server doesn't have the
answer. So, if we have a service to register artifacts on CKM servers
(service 1. on the list above), with an artifact registered notification
protocol, and another protocol for CKM server discovery, we could
implement the distributed search.


 2. Establish references to remote assets, almost certainly caching the
 referenced asset locally

 

This would be the a mix of adding and artifact and artifact registered
notification protocol.


 3. Establish subscriptions to remote assets, to enable change notification
etc
 

And this would be included in the CKM server discovery protocol, that
could defined like some services provided by the NDP protocol, using
messages like RA, NS, NA, ... to discover CKM servers to create a CKM
network over Internet:
http://fengnet.com/book/CCIE%20Professional%20Development%20Routing%20TCPIP%
20Volume%20I/ch02lev1sec5.html 
I think some of these services could be found also in the ICMP protocol:
http://www.networksorcery.com/enp/protocol/icmp.htm

 

 

Just to clarify my thoughts, I don't think we need a network protocol!!! I
think we could create our protocols to handle artifacts in a distributed way
reusing some ideas from those proven protocols that our machines run
everyday to connect to the Internet and access distributed resourses.

 

 

How this stuff could work in reality?

 

1.  We need a set of root CKM servers, always online, that could
answer our queries or redirect to some another server that could answer
(like DNS).
2.  In those servers (could be only one, like openEHR.org CKM), other
servers could advertise themselves to form part of the CKM network, this
could be done like an ICMP or NDP router advertisement. Those servers could
download also a list of servers currently connected to the network, and
update the list anytime.
3.  The children servers could be not always online, so each entry on
the root server registry should have a lifetime, that when reached, the
entry is eliminated from the list (like in ICMP
http://www.networksorcery.com/enp/protocol/icmp/msg9.htm ). This could
trigger a notification to the other members of the network, to update their
server list.
4.  When an artifact is added to a server, it should notify other
servers in the network, so they could know what server has the original copy
of the artifact, and maybe they can make a copy of the artifact that sould
be read-only on those servers that cache a copy. The cached archetype could
have a lifetime, that when reached, a new copy of that archetype should be
downloaded from the original server, if the server is still online, or renew
the lifetime if the original server is offline.
5.  Then a query received by any CKM could be responded or redirected to
other server, and all servers in the network could keep up with all the
archetypes created worldwide.

 

 

I don't know if this is crazy talk or if it's seems reasonable to you.
Please let me know :D

 

 

Kind regards,

Pablo.

 

 

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

openEHR / FHIR data types cross analysis

[Sam Heard]

Thanks Tom for this useful work.

 

A couple of thoughts:

1)  It might be worth explaining the need for DV_BOOLEAN - and not just
use Boolean

2)  The separation of date and time is not usual in computing languages
at the moment and I would guess is a consideration - we certainly do not
model these separately but as a constraint

3)  The ability to have codes as units in quantity is an interesting
approach which has been around for a while in HL7 v2 where you are not
limited to SI units/UCUM but can have TAB for tablets etc.

 

You state: The FHIR choice to represent units as a code or a string seems
unnecessarily complicated. A UCUM units string should be adequate. There is
an example with unit=mcg/L and code=ug. What can this mean?

 

Nota sure how we could have a code for a unit that is UCUM/SI - this does
not make sense really - but having the ability to put in quantities that are
not SI Units does have some merit. Pulse is a good example - it is really a
frequency x/min but people often say bpm or beats per minute. The amount of
tobacco people use can be in cigarettes per day or oz/week or gm/day. At the
moment we have to divide these into different parts of the archetype.

 

That is not to say that it is right to put the counted thing as a unit and
not keep it in the leaf node name but TAB/CAP/Puff/Drop etc are common for
medication and do cause some difficulty.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Monday, 30 January 2012 4:27 AM
To: Openehr-Technical
Subject: openEHR / FHIR data types cross analysis

 


I have started a gap analysis of the openEHR and FHIR data types
http://www.openehr.org/wiki/display/stds/FHIR+-+openEHR+Data+Types+cross-an
alysis , created by Grahame Grieve as part of the HL7 'fresh look'
activity. ANyone is welcome to add to the tables on this page - I am just
slowly working on it in the background.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/8bab1f24/attachment.html

DV_DURATION as ranges

[Sam Heard]

Hi Tom and Diego,
The reference workbench only has an interval constraint on duration as it is
the logical constraint. If this is a point duration then it still expresses
a range. Not sure if this has changed over time.
Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Thomas Beale
 Sent: Tuesday, 31 January 2012 2:51 AM
 To: openehr-technical at openehr.org
 Subject: Re: DV_DURATION as ranges
 
 
 I thought I had replied to this, but must not have. Anyway, I don't
 understand why single point values are not used either, rather than
 point ranges (which seem somewhat pointless ;-)
 
 - thomas
 
 On 25/01/2012 22:56, Diego Bosc? wrote:
  No comments about this one?
 
  2012/1/13 Diego Bosc?yampeku at gmail.com:
  As Ian suggested I copy this issue from CKM to the technical list.
  I have seen that in some archetypes (e.g. Apgar or BloodPressure)
  that use DV_Duration restrictions (such as the width of the interval
  event in the blood pressure archetype or the famous offset in the
  apgar
  archetype) define them like this:
 
  offset existence matches {1..1} matches {
  DV_DURATION[at0040] occurrences matches
  {0..1} matches {  --
  value existence matches {1..1}
 matches {|PT10M|}
  }
  }
 
  As you can see, even if it is a single default value (10 minutes),
  they are defined as ranges. As durations allow the definition of
  default values (and they parse correctly) I think they should be
  changed to this:
 
offset existence matches {1..1} matches {
  DV_DURATION[at0040] occurrences matches
  {0..1} matches {  --
  value existence matches {1..1}
 matches {PT10M}
  }
  }
 
  As checking a concrete value is always easier than a range I would
  suggest to change them to that.
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Does XMLSerializer (java) create archetype slots with too much extra information?

[Sam Heard]

Hi Diego

This was the result of some overzealous efforts in the past (designed to
make XML look verbose :-). The discussion has been about the fact that
Occurrences does not need an includelower/upper and unbounded is not
necessary as it can never be a constraint statement.

The expression is new to me...

Sam


 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Diego Bosc?
 Sent: Wednesday, 4 January 2012 1:18 AM
 To: For openEHR technical discussions
 Subject: Does XMLSerializer (java) create archetype slots with too much
 extra information?
 
 This is a simple question: Why does a simple archetype slot like this
 (ADL)
 
 allow_archetype ELEMENT[at0001] occurrences matches {0..*} matches {
 -- Archetype slot
 include
 archetype_id/value matches {/.*/}
 }
 
 ends up like this?
 
 children xsi:type=ARCHETYPE_SLOT
 rm_type_nameELEMENT/rm_type_name
 occurrences
   lower_includedtrue/lower_included
   upper_includedfalse/upper_included
   lower_unboundedfalse/lower_unbounded
   upper_unboundedtrue/upper_unbounded
   lower0/lower
 /occurrences
 node_idat0001/node_id
 includes
   tag /
   string_expressionarchetype_id/value matches
 {/.*/}/string_expression
   expression xsi:type=EXPR_BINARY_OPERATOR
 typeBOOLEAN/type
 operator2007/operator
 precedence_overriddenfalse/precedence_overridden
 left_operand xsi:type=EXPR_LEAF
   typeSTRING/type
   item xsi:type=xsd:stringarchetype_id/value/item
   reference_typeCONSTANT/reference_type
 /left_operand
 right_operand xsi:type=EXPR_LEAF
   typeString/type
   item xsi:type=C_STRING
 pattern.*/pattern
   /item
   reference_typeCONSTANT/reference_type
 /right_operand
   /expression
 /includes
 
 I'm not complaining about the ultra-verbose occurrences (surely can be
 improved, but there was already a discussion about this on this
 mailing list).
 I don't get the point of putting the 'expression' tags on this case.
 It's like putting the same thing twice.
 Is the 'operator' tag supposed to be understandable?
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

13606 revisited - list proposal

[Sam Heard]

Hi David

 

While I agree with your sentiment as a technical guy, the fact is that
sharing health information will be more important than the application space
relatively soon. This is like document sharing now ? you can have the best
word processor on the planet but if it doesn?t do word then it isn?t really
much use.

 

Things can only change slowly once standardisation creeps in ? so we want to
liberate the application from the EHR. Providers and consumers owning the
EHR and vendors the application spaces.

 

Cheers, Sam

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of David Moner
Sent: Friday, 16 December 2011 10:55 PM
To: For openEHR technical discussions
Subject: Re: 13606 revisited - list proposal

 

Hi,

2011/12/16 Erik Sundvall erik.sundvall at liu.se

Hi!

 

As you know, if you want to truly bi-directionally share things for
which it is impossible to define deterministic conversion
algorithms/programs (thus maintaining patient safety in automated
conversions), then just defining a standard message- or extract format
will be a lost cause (no matter how determined politicians are and no
matter how much you pay IT-consultants to try to do the job). Instead
the semantics of the end point systems will need to be aligned sooner
or later.

 

I completely agree. But aligned does not mean that the have to be exactly
the same. Conversions between models and standards will always be needed.

 

Anyway it wouldn't hurt if a new or refreshed internationally
recognized standard could be used by those vendors and system owners
that actually _want_ to agree on the internal clinical semantics of
efficiently implementable systems all the way down to some of the
technical (e.g. openEHR inspired) details. I think there is now a
market for such a standard (or new standard part) helping those that
have given up beliefs in mapping of incompatible semantics.

 

 

The problem is that a unique solution will never be used by all actors (due
to the human nature of divergence). The need of interoperability between
different solutions and systems will always exist and then we have to give a
solution for this scenario. Best practices maybe will commonly accepted, but
no specific solutions probably.

 

 From our
 experience, interoperability between legacy systems (standard-based or
not)
 is much easier using a generic model for exchange. The harsh truth is that
 the quality of the data and the design of information structures in
existing
 EHR systems is quite bad or unclear, thus making really complicated the
 process of automatically transforming it to a very specific reference
model.
 This is not the case when we use 13606.

I suspect this is an intentional difference between current 13606 and
openEHR; to faithfully capture the current (incompatible) situation
versus aiming to change the current situation.  Can those different
goals really meet in one RM or do we need two standardized RMs?
http://dilbert.com/strips/comic/2011-08-02/

 

I talked of this with Thomas last August in Oslo. For me, the ideal solution
would be to have a unique model that covers both needs. It should include
generic classes such as those of 13606 and inherit from them specific
classes for building EHR systems, as those of openEHR. Technically it should
be possible to have, for example, a generic
COMPOSITION-ENTRY-CLUSTER-ELEMENT structure that can be instantiated, but
also a COMPOSITION-OBSERVATION-ITEM_TREE-ELEMENT structure inherited from
it. An implementer could choose then to just create instances of the generic
classes (e.g. for exchange) or instances of the specific ones, that are
compatible (e.g. for operational systems). Note that this is currently not
possible since ENTRY is an abstract class in openEHR.

 

A side-track question: Do you feel that the archetyped approach with
13606 really helps in the current mappings/transformations that you
work with more than what just using e.g. RDF+OWL would help? Or does
the archetype stuff and RM mostly complicate things?

 

 

It definitely helps. On the one hand because we deal with data
transformations and then it is essential to have a clearly defined reference
or information model to shape the data that is going to be communicated. And
on the other hand, archetypes are the target schema for these data. We will
all agree that the dual model is the best way to have together the three
basic ingredients of semantic interoperability: the data structure, the
concept definition and the binding to terminologies.

 

 A different thing is if 13606 scope changes during the revision. In that
 case, I agree that reducing layers of modelling by introducing specific
 classes will make the systems more efficient.

Is there an opening for scope-change or not within the formal
13606-revision or would one need to start a completely new standard in
order to define a standard for aligning internal EHR system semantics?

 

I have no idea. 

Questions about the relationship between Instruction, workflow and Action

[Sam Heard]

Hi Pablo,

 

The design principles are that the Instruction should remain unaltered by
people basing actions on this instructions ? as the action and instructions
could be disconnected at any moment. For example, the instruction
(medication order) should not be changed by anyone just to give a medication
etc.

 

So the state of the instruction is carried in the record of the action (if
appropriate). We have decided to name the pathway steps and attach a machine
readable state to that step. This makes it much easier for clinicians to
model and to see what is going on.

 

In our openEHR repository we maintain an instruction index ? that is a
pointer to all instructions and all actions that relate to that instruction
? and the current state of the instruction. 

 

You will see an archetype ACTION in the openEHR repository and the
careflow_steps are archetyped to provide a name and the current state
matches an openEHR code for state. This means that a careflow step being
carried out will set the state to a particular machine state.

 

Hope this helps.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Wednesday, 7 December 2011 9:19 AM
To: openehr technical
Subject: RE: Questions about the relationship between Instruction, workflow
and Action

 

Nobody? :'(

Maybe is better just one question at a time, sorry for that.

  _  

From: pazospa...@hotmail.com
To: openehr-clinical at openehr.org; openehr-technical at openehr.org
Subject: Questions about the relationship between Instruction, workflow and
Action
Date: Sun, 4 Dec 2011 15:36:36 -0300

Hi everyone!

 

I'm trying to understand how to execute a state machine of a fully
structured INSTRUCTION, and I have some questions and thoughts to share with
you...

 

 

The first issue is about archetyping an ACTION that execute and ACTIVITY of
an INSTRUCTION. Modeling an ACTION, the Archetype Editor let me archetype
the ACTION.ism_transition attribute, but not the ACTION.instruction_details.
Both attribute classes (ISM_TRANSITION and INSTRUCTION_DETAILS) are
specializations of PATHABLE, so those shouldn't be archetypable (see
http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 53).

Is this a bug in the AE or is an issue in the specs?

 

 

If the ACTION.instruction_details attribute can't be archetyped in the AE,
how could I know what specific structure the
ACTION.instruction_details.wf_details attribute will have?

 

 

Is the ACTION.instruction_details.wf_details attribute related somehow
with the ACTIVITY.description attribute?

 

 

The description of the ACTION.instruction_details.wf_details attribute
says: condition that fired to cause this Action to be done (with actual
variables substituted),

What is the meaning of with actual variables substituted? This makes me
think having an ACTIVITY in memory, creating an instance of an ACTION to
record the execution of that ACTIVITY, copying the ACTIVITY.description
structure into the ACTION.instruction_details.wf_details, and the update the
correspondent fields into the wf_details with actual execution data.

 

Does this make any sense? or I'm just to twisted :D

 

 

 

The last one!

Now only ACTIONs can change a state on the ISM, but I think an ADMIN_ESTRY
could change the state also, e.g. to move a planned procedure to the
scheduled state, there is an administrative step of coordinating date 
time, not a clinical action. Again, does this make any sense?!

 

 

 

Thanks a lot!


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


___ 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/20111207/48c14f98/attachment.html

Could YAML replace dADL as human readable AOM serialization format?

[Sam Heard]

Hi All

 

I am going to say it once more:

 

If there is an expression on occurrences of '0..*' anywhere in ADL then it
is an error, for that is not a constraint - and can only be wrong (ie the RM
may have a narrower constraint). We just need a max int and a min int - both
optional.

 

I won't say it again - but it does keep it simple and it is correct!

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel
Sent: Monday, 5 December 2011 8:40 AM
To: 'For openEHR technical discussions'
Subject: RE: Could YAML replace dADL as human readable AOM serialization
format?

 

I think previously I had indicated I had no problem with the stringified
interval approach in XML, but I am reverting my thinking on this and feel
that it would be counter intuitive for those who what to use the XML schemas
for code generation purposes.  I think in this case the computable
requirement outweighs the human readable requirement.  I think we can come
up with a much more concise representation of these intervals without
compromising the computable requirement, something similar to XML schema
maxOccurs/minOccurs.

 

Heath

 

please everyone remember that the dADL, JSON and XML generated from AWB all
currently use the stringified expression of cardinality / occurrences /
existence. Now, these are usually the most numerous constraints in an
archetype and if expressed in the orthodox way, take up 6 lines of text,
hence the giant files (e.g. AOM 1.4 based XML we currently use) - and thus
the much reduced files you see on Erik's page, because we are using ADL 1.5
flavoured serialisations not the ADL 1.4 one.

Now, I think we should probably go with the stringified form in all of these
formalisms. The cost of doing this is a small micro-parser, but it is the
same microparser for everyone, which seems attractive to me.

The alternative that Erik mentioned was more native, but still efficient
interval expressions, e.g. dADL has it built in (0..* is |=0| in dADL), and
YAML and JSON could probably be persuaded to make some sort of array of
integer-like things be used. XML still doesn't have any such support. In
theory this approach would be the best if each syntax supported it properly,
but XML doesn't at all, and the others don't support Intervals with
unbounded upper limit (i.e. the '*' in '0..*'). 

But Erik's exercise certainly proved that efficient representation of the
humble Interval Integer is actually worthwhile. (Once again thanks for
that page, its quite a good way to get a good feel for these syntaxes very
quickly).

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111205/21dc776f/attachment.html

occurrences and cardinality in ADL, XML, JSON

[Sam Heard]

Hi All

As ADL only states constraints there is no logical reason to include unbounded. 
So no constraint expressed  = RM max. This is likely to be one or unbounded.


Sent from my phone

On 11/11/2011, at 5:11 AM, Thomas Beale thomas.beale at oceaninformatics.com 
wrote:

 
 In the current ADL 1.4-based XSDs used in openEHR, occurrences, cardinality 
 and existence are expressed as XML elements. We will want to improve this for 
 ADL 1.5 based XML. Now, we don't want to only take care of XML; we also need 
 to make it work for JSON, and (internally) for dADL - neither of the latter 
 have XML's 'attributes'. Many people have asked for more efficient ways of 
 serialising. Here are some ideas for ADL 1.5 XML, JSON etc.
 
 ~~ first question: occurrences and cardinality  
 Occurrences and cardinality  are proper intervals in the AOM representation. 
 The most simplified object structure (JSON and dADL) for occurrences and 
 cardinality could look as follows (I use dADL  occurrences here):
 
 occurrences = 
 lower = 2 -- Integer field
 upper = 10 -- Integer field
 
 
 but the upper limit is commonly unbounded, i.e. '*' in typical UML-like 
 syntax. We could do:
 
 occurrences = 
 lower = 2 -- Integer field
 upper_bounded = True -- Boolean field
Sam: no need for this.
 
 
 meaning that 3 possible attributes could occur for an occurrences, but only 
 ever 2 at the same time. Or we could make everything into a string:
 
 occurrences = 
 lower = 2 -- String field
 upper = * -- String field
 
Sam: no need for this
 
 The upside is that the 'upper' attribute now handles both bounded and 
 unbounded values. The downside is that the JSON / dADL parsers would have to 
 do a bit more work to generate the required IntervalInteger object - since 
 the 'upper' attribute now has to be treated as a little fragment of syntax 
 and checked before being turned into an Integer. 
 
 If we were just doing JSON, dADL and other 'proper' OO syntaxes, the first 
 one would be the obvious one. But since we are also targetting XML, we have 
 to think whether it makes more sense to do:
 
children node_id=at0005 occurrences_lower=2 
 occurrences_upper=10 -- xsi:type=C_OBJECT
rm_type_nameCLUSTER/rm_type_name
  
 and
 
children node_id=at0005 occurrences_lower=2 
 occurrences_unbounded=true -- xs:boolean has to support 0/1 and true/false
rm_type_nameCLUSTER/rm_type_name
  
 which is the analog of the first approach above, or it could be:
 
children node_id=at0005 occurrences_lower=2 
 occurrences_upper=10
rm_type_nameCLUSTER/rm_type_name
  
 and
 
children node_id=at0005 occurrences_lower=2 occurrences_upper=*
rm_type_nameCLUSTER/rm_type_name
 
 with both attributes defined in the XSD as xs:string. This means that like 
 for JSON/dADL, the XML standard parser only generates strings, and somehting 
 further has to be done to obtain a proper Interval object. 
 
 My preference is still to go with the first way of doing things. Do others 
 agree with this? If so, it is what I will implement in the ADL 1.5 workbench. 
 
 ~ second question:existence 
 Existence as an interval can be 0..0 (prohibited, commonly used in 
 templates), 0..1 (optional, typical in the RM) and 1..1 (used in templates 
 and sometimes in archetypes). Now, since archetypes and templates are 
 constraint structures, they can only further constrain the RM in ADL/AOM 1.5. 
 The only possibilities for this are actually 0..0 and 1..1, so we could 
 collapse existence onto a single Boolean for serialised representation (it 
 could also be a single Boolean in the AOM, but that would be a breaking 
 change, and since we already use Intervals for occurrences and cardinality, 
 it does not seem worth the trouble). 
 
 Thus in JSON/dADL it could be:
 
 some_attr = 
 existence = True|False
 
 
 In XML:
 
 attributes rm_attribute_name=nameexistence=true

 /attributes
 
 Now, this is cheating a bit because we are making it look like there is an 
 AOM property 'existence' of type Boolean, but there isn't. Should it be named 
 something else to make this clear? I.e. a pseudo attribute that only exists 
 in serialised format but not in AOM internal format, e.g. 
 'existence_constraint'? I would favour this. In my current implementation, 
 the serialised format actually has its own object model, and this would have 
 to be true for JSON as well. I think it also makes sense in XML - that there 
 will be a level of classes corresponding to the space-efficient serial form, 
 which are not the same as the internal AOM classes.
 
 thoughts?

Agree, it could be 0 or 1
 
 - thomas beale
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML 

openEHR course in spanish

[Sam Heard]

Hi Pablo

This looks excellent. There is some repetition but it is clear that you are
providing an overview in the first classes and drilling down in later
classes. I would suggest that you might actually introduce some of the tools
a little earlier as people will have more fun if they can build or edit some
models.

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Tuesday, 18 October 2011 7:36 AM
To: openehr clinical; openehr technical; openehr implementers2
Subject: openEHR course in spanish

 

Hi,

 

I'm trying to impart a course on openEHR for spanish speakers audiences,
here is the agenda for the course:
http://informatica-medica.blogspot.com/2011/10/curso-de-openehr-en-espanol.h
tml

 

Please click on the ENGLISH link on the top-right corner to translate the
page.

 

This are my 2 cents in spreading openEHR in the latin-american medical
informatics communities.

 

It would be nice to have the feedback of the openEHR community on the topics
of the course. Any comments, sugestions, references, resources, etc, are
very welcome!

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

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

openEHR Archetypes Development

[Sam Heard]

Hi Laura

 

Thanks for the link. I am finding it very difficult to make head or tail of
the pages and what it all means.

The pages appear to have a very basic 13606 element at the top and then a
heap of references including self references.

 

Can you help at all?

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sato Laura (NHS
CONNECTING FOR HEALTH)
Sent: Friday, 7 October 2011 11:34 PM
To: For openEHR technical discussions
Subject: RE: openEHR Archetypes Development

 

In part in (a slow!) response to the discussion below, I'm pleased to invite
comments on the current draft detailed content models (based on 13606 and
using the SNOMED CT concept model) for Discharge Summary, now accessible at
https://svn.connectingforhealth.nhs.uk/svn/public/lra/PUB/discharge/content/
index.html.  (Apologies for the certificate warning that you'll be
confronted with at first.)

 

For some background info, this work is still relatively rough - it's an
interim draft release that shows our first attempt to publish a full suite
of detailed requirements, technical models and instance examples for record
content.  We're aware of a few inconsistencies and gaps in the end-to-end
flow, but I'd still welcome any comments you might have time to send us ...
I'm hoping that we'll release the next draft (based on comments received in
the next few weeks) in November.

 

Best wishes,

Laura

 



Laura Sato

Head, Logical Record Architecture

 

Department of Health Informatics Directorate

Technology Office, NHS Connecting for Health

 

email: laura.sato at nhs.net

mobile: (44) (0)7733 324 338

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Eunice Ab
Sent: 03 June 2011 12:18
To: For openEHR technical discussions
Subject: Re: openEHR Archetypes Development

 

Dear Laura, Ian

 

Many thanks for your emails. They have been so helpful .

 

Laura, I am going to take up the offer of contacting you to get to know more
about the 'central activities'. I will be in touch soon.

 

Ian, I totally agree that most of the work done on data standards is
currently been hidden away behind the N3 firewall or through trud. We need
more accessible mechanisms for this work expecially for those that actually
need to use these standards locally.

 

Hopefully this will be taken into consideration in current and future work.

 

Thanks again.

 

Best regards

 

Eunice

 

On 3 June 2011 10:44, Ian McNicoll Ian.McNicoll at oceaninformatics.com
wrote:

Thanks Laura,

That is very helpful clarification. It is unfortunate that much of the
interesting work being done in the English NHS is 'hidden away' either
with the TRUD mechanism or in the case of the Clinical Data Standards
work, behind the N3 firewall. I know steps are being taken to address
these issues but it does present a significant barrier for those
outside the NHS.

Regards,


Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
 +44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care  www.phcsg.org http://www.phcsg.org/ 




On 3 June 2011 10:28, Sato Laura (NHS CONNECTING FOR HEALTH)

laura.sato at nhs.net wrote:
 Dear Eunice,



 For info, although NHS Data Standards  Products has worked with openEHR
 archetypes in the past, we are currently working on developing care record
 content models that use the EN/ISO 13606 reference model and ISO 21090
data
 types (both with a relationship to, but not exactly the same as, openEHR's
 technical infrastructure), alongside a modelling approach that seeks to
make
 as much use as possible of the SNOMED CT clinical concept hierarchy, as
well
 as re-usable ELEMENT models and terminology constraints.  Do please feel
 free to get in touch with me, if you'd like more information about current
 NHS 'central' activities in this area.



 We also continue communications with Thomas and Ian (and others) to
maintain
 links with the openEHR community, and hopefully will be able to provide a
 clearer picture of how NHS content and openEHR archetypes fit together in
 the coming months.



 Best regards,

 Laura



 

 Laura Sato

 Head, Logical Record Architecture



 Department of Health Informatics Directorate

 Technology Office, NHS Connecting for Health



 email: laura.sato at nhs.net

 mobile: (44) (0)7733 324 338









 From: openehr-technical-bounces at openehr.org
 [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Eunice Ab
 Sent: 19 May 2011 18:22
 To: For openEHR technical discussions
 Subject: Re: openEHR Archetypes 

Tools for collaborative working

[Sam Heard]

Dear All

The Board is interested in using tools for collaborative online working and
keeping these coordinated. We already have Jira and Confluence from
Atlassian. These are working well as far as I am aware.

I would like to propose that we consider going to third parties for:

Source code repository
- Bitbucket from Atlassian (Mercurial)
  - ? other options

Agile development
- Pivot Tracker (I have applied for 4 accounts for free - openEHR
Specifications, openEHR Software, openEHR Clinical Models, openEHR
Localisation) Projects would then be created under each of these by the
Members if we chose to use this tool.
- ? other options

Please discuss these issues. I have asked a couple of the less technical
people to review Pivot Tracker to consider its role in tasks other than
software development.

We will obviously be guided totally by the lists on these matters - the
point being that we really want to use one tool for one purpose across
different programs if possible or appropriate. Even if the tool turns out
not to be the best one at times, the uniformity will be very important going
forward.

Cheers, Sam


Dr Sam Heard
Chief Executive Officer
Director, openEHR Foundation
Senior Visiting Research Fellow, University College London

214 Victoria Avenue
Chatswood, NSW, 2067
Phone: +61 2 9415 4994
Mobile: +61 4 1783 8808
21 Chester Cres
London E8 2PH
Phone: +44 20 7249 7085
Mobile: +44 75 7549 7937 

openEHR Transition: Web-based tools?

[Sam Heard]

Hi Ian

My interest is the pain we get as the tools get developed and tweaked as does 
ADL and multiple versions. 

Also, if we are to use Thomas' engine it should tip the balance a bit further 
as installing and updating numerous layers gets even more painful.

Finally, web tools are easier to access on multiple devices including mobile.

Cheers San

Sent from my phone

On 10/09/2011, at 1:10 AM, Ian McNicoll Ian.McNicoll at oceaninformatics.com 
wrote:

 Hi all,
 
 One of the suggestions in the White Paper which appears to have
 universal support is a move to support much more open-source tools
 development. Clearly some tooling must be web-based e.g repository
 management and associated formal and informal discussion e.g. CKM and
 any new community repository.
 
 However, I am much less clear on why we might need web-based primary
 authoring tools for archetypes and templates. Diego, Pablo and Sam are
 all keen on this approach but I remain unconvinced that this is really
 a key requirement, given that archetype authoring is in essence a
 solitary activity much like any other code development. By all means
 build in much better integration with repositories and other
 mechanisms to allow joint working, but even with modern javascript
 libraries and Flex-style components, HTML-based tooling just feels
 like it adds a layer of development complexity and probably some
 usability-clunkiness which is not offset by the benefits.
 
 Maybe I am just an old-timer but having waited for may years to get
 the kind of development environment that Visual Studio, Eclipse and
 equivalents bring, and that I think is equally required for archetype
 development, I am loathe for us to get slowed-down by insisting on a
 'web-based'.
 
 What do others think?
 
 Ian
 
 Dr Ian McNicoll
 office +44 (0)1536 414 994
 fax +44 (0)1536 516317
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com
 
 Clinical Modelling Consultant, Ocean Informatics, UK
 openEHR Clinical Knowledge Editor www.openehr.org/knowledge
 Honorary Senior Research Associate, CHIME, UCL
 BCS Primary Health Care  www.phcsg.org
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

EN/ISO 13606 openEHR - harmonisation possibilities

[Sam Heard]

As Dipak has explained, the attribution in ISO is not available. I believe 
attribution is a distraction from the task - I have seen lots of slides from 
others used in this space and ideas transferred here and there. Let's 
appreciate all work and try and build on it efficiently.

Cheers Sam

Sent from my phone

On 10/09/2011, at 5:05 AM, Thomas Beale thomas.beale at oceaninformatics.com 
wrote:

 On 09/09/2011 19:04, David Moner wrote:
 
 Thomas,
 
 Could you please clarify this sentence?
 
 I'm the main author of that document. As you said, it is a 45 pages 
 document of which only two and a half are a summary description of ADL 
 to understand the proposed archetypes. And only there we can see some 
 examples of ADL structures (yes, openEHR ones) taken directly from 
 EN13606-2, which is the norm referenced at the document, and not from 
 the openEHR specifications.
 
 I really think that your affirmation is misleading and unfair.
 
 David,
 
 sorry - you are right, there is not 'a lot' of copied material, only p 
 11  12. But I do find it funny that there is no mention of openEHR, 
 because it means that readers of the document won't realise that they 
 should go to openEHR to see ongoing developments in the specification 
 and tools (I am not saying the only development in tools of course, but 
 since 13606-2 is a snapshot of an openEHR spec, it would make sense to 
 make this clear, one would have thought).
 
 - thomas
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Hi Tom

It is normal practice with CC to include clarifications and the whole
structure of the license is designed to do this.

Let's stay with the issue of how we stop someone copyrighting and charging
for a specialised archetype? Or a template that is fundamental to health
care (like an antenatal visit)?

Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Thomas Beale
 Sent: Thursday, 8 September 2011 10:30 AM
 To: openehr-technical at openehr.org
 Subject: Re: openEHR Transition: two procedural and one licensing
 question
 
 On 07/09/2011 21:46, Sam Heard wrote:
  Thanks Stef
 
  The previous Board did not want to make an error and use too loose a
  licence given that there is no going back.
 
  Our concern is that someone could specialize an archetype and claim
  copyright, or create a template and do the same. It is our intention
  at this stage to have a specific clause in the licence that limits it
  to derived archetypes and templates.
 
 I don't think actually changing the text of any accepted, well known
 license is a good idea at all - then it becomes something for which no
 legal analysis is available, and won't be trusted by anyone. Instead,
 openEHR should simply state which kinds of artefacts require which
 kinds
 of license (if any).
 
 - thomas
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Well that may be true but government agencies and companies will want to know 
that no one has recourse to legal action if they use an archetype.

Cheers Sam

Sent from my phone

On 09/09/2011, at 8:21 AM, Timothy Cook timothywayne.cook at gmail.com wrote:

 On Thu, Sep 8, 2011 at 16:54, Sam Heard sam.heard at oceaninformatics.com 
 wrote:
 Hi Tom
 
 It is normal practice with CC to include clarifications and the whole
 structure of the license is designed to do this.
 
 Let's stay with the issue of how we stop someone copyrighting and charging
 for a specialised archetype? Or a template that is fundamental to health
 care (like an antenatal visit)?
 
 Maybe that isn't such a bad thing.  They are only roping themselves
 into their own corner.
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Thank you Shinji, this is an excellent idea - to really put support for 
language and other localization at the heart. I would propose that one 
Organisation become an associate and manage local activites - which 
Organisation should be by a vote of local associates.

This prevents the need for a lot of administrative activity.

What do others think?

Cheers Sam

Sent from my phone

On 07/09/2011, at 10:15 PM, Shinji KOBAYASHI skoba at moss.gr.jp wrote:

 Hi Sam and all
 
 Thank you for comments about localisation.
 First of all, I emphasize LOCALISATION is not ISOLATION.
 Only to fork and arrange global resource for local usage is isolation.
 True localisation is to feed back such experience to enrich core
 implementation.
 I think endorsement program at page 4 of white book should include
 localisation as global promotion, and endorsement / promotion program
 should have a board like other specification / clinical modeling / software
 engineering.
 Because local activity management depends on its own domestic situation,
 local governance should be decided by local community. However, bad
 localisation disgrace all of our community and makes people unhappy in its 
 area.
 So I think local activity requirements are,
 * Keep contact with global community
 * Implement openEHR clinical models for domestic use.
 * Provide proper translation, specialised implementation for their domain.
 * Promote openEHR specification for their domain.(Web/mailing list)
 * Governance of local community as good status
 * Feed back localisation experience to global community.
 I also think two or three of these conditions are enough to be a local 
 activity.
 
 These are my requests from Japan(probably from other local activities, too)
 * Permit to use openEHR name and logo for domestic promotion.
 * Publish local activity directory for whom need to contact with them
 on the openEHR.org web.
 * Disallow to use openEHR  name and logo whenf you think we are not
 worth to use.
 * Keep contact with local activities.
 
 Cheers,
 Shinji KOBAYASHI
 
 2011/9/7 Sam Heard sam.heard at oceaninformatics.com:
 Hi Pablo and Shinji
 Supporting localization both technical and operational needs to be included.

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Thanks Stef

The previous Board did not want to make an error and use too loose a licence 
given that there is no going back.

Our concern is that someone could specialize an archetype and claim copyright, 
or create a template and do the same. It is our intention at this stage to have 
a specific clause in the licence that limits it to derived archetypes and 
templates. At all discussions with industrial parties this has been acceptable, 
many see it as positive as the corollary of Eric's approach (which may be the 
best) is that there are heaps of archetypes out there that have openEHR 
attribution but are copyright to other parties.

Is it clear what I am saying. It is a conundrum - and needs careful appraisal 
before going to BY alone.

Cheers Sam

Sent from my phone

On 07/09/2011, at 10:38 PM, Stef Verlinden stef at vivici.nl wrote:

 
 Op 7 sep 2011, om 09:55 heeft Erik Sundvall het volgende geschreven:
 
 Do read that wikipage and follow the links there to the mail
 discussions. What is it that you think is missing or unclear in the
 arguments against SA?
 
 
 
 That they're hidden in a lot of text form which one has to follow through 
 hyperlinks and read even more text.
 
 You stated somewhere - correctly - that companies want to avoid risk, 
 similarly decision makers want to avoid reading through lengthy discussion 
 (from which they have to draw there own conclusions:-) )
 
 
 If I understand you correctly your main argument is that:
 
 the share alike (SA) requirement will create a risk for lengthy juridical 
 procedures - in every country they operate - for companies  who include 
 openEHR archetypes or derivatives thereof in their systems. Since companies 
 avoid risk, they  will choose other solutions without an SA requirement.
 
 The reason for this is that it's not clear what SA exactly means. For 
 instance in the context of building archetype-based GUI- stubs, forms etc. in 
 proprietary systems. As a consequence it could be possible that companies are 
 forced - unwillingly - to open up the source of their proprietary systems. It 
 will take years and many court cases, in different countries, to sort this 
 out. Until then (the large) companies will stay away from openEHR.
 
 This problem can be avoided completely by dropping the SA requirement.
 
 
 So I guess the first question is: who has a solid argument against Erik's 
 argument.
 
 The second question is: what are the exact benefits of the SA requirement and 
 are they worth the risk of companies not using openEHR at all (presuming 
 that's a real risk).
 
 
 Cheers,
 
 Stef
 
 
 
 ___
 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/20110908/b6e24d5e/attachment.html

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Hi Tim, 
It is tangled up with the CC-BY-SA question. Some one needs to have the 
copyright or there is a license agreement that is evoked as you enter the the 
archetype in the repository.

Our advice was that having copyright simplifies the world. Having said that the 
same archetypes now exist in other repositories with copyright assigned to the 
national provider, so it is already murky.

The real point is that interoperability depends on sharing archetypes, which 
need to be available for use without regard to others. 

By that, I also mean I can freely use ANY archetype or template out there if I 
need to.

Cheers Sam

Sent from my phone

On 08/09/2011, at 9:05 AM, Timothy Cook timothywayne.cook at gmail.com wrote:

 Sam,
 
 Just to be clear.  Is it yours and the boards intent that all
 archetypes and templates be marked as copyright openEHR Foundation?
 
 Thanks.
 
 On Wed, Sep 7, 2011 at 15:46, Sam Heard sam.heard at oceaninformatics.com 
 wrote:
 Thanks Stef
 The previous Board did not want to make an error and use too loose a licence
 given that there is no going back.
 Our concern is that someone could specialize an archetype and claim
 copyright, or create a template and do the same. It is our intention at this
 stage to have a specific clause in the licence that limits it to derived
 archetypes and templates. At all discussions with industrial parties this
 has been acceptable, many see it as positive as the corollary of Eric's
 approach (which may be the best) is that there are heaps of archetypes out
 there that have openEHR attribution but are copyright to other parties.
 
 Is it clear what I am saying. It is a conundrum - and needs careful
 appraisal before going to BY alone.
 Cheers Sam
 Sent from my phone
 On 07/09/2011, at 10:38 PM, Stef Verlinden stef at vivici.nl wrote:
 
 
 Op 7 sep 2011, om 09:55 heeft Erik Sundvall het volgende geschreven:
 
 Do read that wikipage and follow the links there to the mail
 discussions. What is it that you think is missing or unclear in the
 arguments against SA?
 
 That they're hidden in a lot of text form which one has to follow through
 hyperlinks and read even more text.
 You stated somewhere - correctly - that companies want to avoid risk,
 similarly decision makers want to avoid reading through lengthy discussion
 (from which they have to draw there own conclusions:-) )
 
 If I understand you correctly your main argument is that:
 the share alike (SA) requirement will create a risk for lengthy juridical
 procedures - in every country they operate - for companies  who include
 openEHR archetypes or derivatives thereof in their systems. Since companies
 avoid risk, they  will choose other solutions without an SA requirement.
 The reason for this is that it's not clear what SA exactly means. For
 instance in the context of building archetype-based GUI- stubs, forms etc.
 in proprietary systems. As a consequence it could be possible that companies
 are forced - unwillingly - to open up the source of their proprietary
 systems. It will take years and many court cases, in different countries, to
 sort this out. Until then (the large) companies will stay away from openEHR.
 This problem can be avoided completely by dropping the SA requirement.
 
 So I guess the first question is: who has a solid argument against Erik's
 argument.
 The second question is: what are the exact benefits of the SA requirement
 and are they worth the risk of companies not using openEHR at all (presuming
 that's a real risk).
 
 Cheers,
 Stef
 
 
 ___
 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
 
 
 
 
 
 -- 
 
 Timothy Cook, MSc
 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 openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Hi Pablo and Shinji

Supporting localization both technical and operational needs to be included. 
The no language primacy principle is a real winner, different written forms of 
the same language is not covered as yet. 

How local groups run is another, clearly these can be national or context based.

Thanks for the input.

Cheers Sam

Sent from my phone

On 07/09/2011, at 2:38 AM, pablo pazos pazospablo at hotmail.com wrote:

 Hi Shinji,
 
 That's exactly what I tried to point in another mail to the lists: local and 
 regional openEHR organizations should be supported by openEHR and we need to 
 put it into the white paper.
 
 -- 
 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, 6 Sep 2011 19:13:45 +0300
  Subject: Re: openEHR Transition: two procedural and one licensing question
  From: skoba at moss.gr.jp
  To: openehr-technical at openehr.org
  
  Hi All,
  
  I have been suffered by sever jet lag after long trip, while I have
  been thinking about this new white
  paper and our local activity. I could not find such localisation
  activity in this white paper, but please
  consider and mention about such local activity.
  I would like to show these two proposals.
  1) Local activity support.
  As a global standard, localisation to each country or area is
  necessary. My three years experience
  to implementation of the Ruby codes, archetypes and template, we need
  lots of localisation efforts
  for Japanese use. I think this experience may be available to localise
  for other countries. East Asian
  countries people is keen in openEHR development and their engagements
  are promising for their
  health care.
  
  2) Premature artefact repository
  CKM provides us well-considered archetypes and templates. This is a
  great knowledge resource
  for mankind. However, to incubate archetype as a common concept takes
  long time like vintage wine.
  On the other hand, I need more agile movement for daily development. I
  have developed about 50
  archetypes and 6 templates. These artefacts are still premature to
  evaluate on CKM, but I would
  like to discuss about my artefacts on line with many people. Yes, it
  will be a 99% junk repository,
  but 1% diamond would be a precious for our community. As Major league
  cannot exist without
  minor leagues, I think CKM needs such minor artefacts groups.
  I am preparing to share them on GitHub, because anyone can use
  repository for each use by fork
  and merge request is useful.
  I think the licence of this repository would adopt CC-BY-SA, is this
  OK, Erik and Ian?
  
  Cheers,
  Shinji KOBAYASHI(in Japan, a path of typhoon.)
  
  2011/9/6 Erik Sundvall erik.sundvall at liu.se:
   Thanks for replying Sam!
  
   Erik Wrote (to openEHR-technical at openehr.org):
   Was that whitepaper formally ratified by the new board, or by the old 
   board,
   or is it's current state just a suggestion by Sam?
  
   On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at 
   oceaninformatics.com wrote:
   [Sam Heard] The whitepaper was ratified by the participants in the 
   planning
   process, the current Board (Profs. Kalra, Ingram and myself) and the new
   Transitional Board.
  
   This is a bit worrying for the period until a broader board can be
   elected. I was hoping that somebody within the new board would be
   interested enough and have time to take licensing issues and community
   feedback seriously, let's hope that the board does a bit more research
   and community dialogue before ratifying a new version of this
   whitepaper. Could somebody from the board please confirm that you'll
   take a serious look at this in the near future?
  
   Erik wrote:
   What is the mandate period of the transitional board? When will the
   suggested new structure with an elected board start?
  
   On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at 
   oceaninformatics.com wrote:
   [Sam Heard] I for one am very happy to express a date for elections if
   organisations embrace these arrangements. Clearly if there is no 
   interest in
   participating from industry or organisations then we would have to think
   again. I suspect we will then move to election of the Board by Members 
   but
   it is our wish to provide a means of determining the governance for
   openEHR?s key sponsors. The aim is to balance the Members with governance
   from the funders and sponsors. Some may prefer a democratic organisation 
   top
   to bottom; we do not think this will achieve the best results.
  
   So there is no absolute end date set. :-(
  
   The if organisations embrace these arrangements part is worrying,
   especially since we already have seen failed attempts at getting
   buy-in from organisations.
  
   Can't you set an absolute latest date (e.g. at the very latest
   December 31, 2012) when the new arrangements will start

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Hi Erik

 

Plans seem to take some promising directions even though that whitepaper
at...

http://www.openehr.org:/openehr/321-OE/version/default/part/AttachmentDa
ta/data/openEHR%20Foundation%20moving%20forward.pdf

...still needs some serious editing in order to better strengthen trust in
openEHRs future.

 

[Sam Heard] Getting the balance of top down governance and sponsorship and
bottom up participation and 'ownership' is difficult and we have worked hard
to get it right. This paper is seeking to set the scene and morph into one
or more clear statements of intent. 


1. First a procedural question:
Was that whitepaper formally ratified by the new board, or by the old board,
or is it's current state just a suggestion by Sam? 

[Sam Heard] The whitepaper was ratified by the participants in the planning
process, the current Board (Profs. Kalra, Ingram and myself) and the new
Transitional Board.

I know for sure that some people in the acknowledgements...

 Acknowledgements: Thank you to David Ingram, Dipak Kalra, Thomas Beale,
 Martin van der Meer and Tony Shannon for assisting in the planning.

...would likely object to part of it's current content.

[Sam Heard] It is obvious that there will be parts of the document that are
not considered ideal by all the participants in its development. These have
been thrashed out and we have presented the best first cut.

2. A second procedural question:
What is the mandate period of the transitional board? When will the
suggested new structure with an elected board start? That date seems to be
missing in the mail and in the document, but having an end date is very
likely important for building trust in any kind of stated interim governance
system (ask the people in the middle east and northern Africa...).

[Sam Heard] I for one am very happy to express a date for elections if
organisations embrace these arrangements. Clearly if there is no interest in
participating from industry or organisations then we would have to think
again. I suspect we will then move to election of the Board by Members but
it is our wish to provide a means of determining the governance for
openEHR's key sponsors. The aim is to balance the Members with governance
from the funders and sponsors. Some may prefer a democratic organisation top
to bottom; we do not think this will achieve the best results.

I am interested in the views of Members.

3. A document content change suggestion:
Remove the CC-BY-SA part in the licencing discussion (page 5) since it makes
the document authors and anybody ratifying it look incompetent. Saying that
original things are CC-BY and that derivative models should be CC-BY-SA is
just plain stupid. Then the originals are NOT CC-BY. It's just as silly as
saying that a piece of open source code is licenced under Apache II licence
but that any derivative code must be licenced under GPL... 

[Sam Heard] The point you are making I think refers to:

---

Clinical Models

Archetypes, Templates and Terminology subsets developed by the community

Creative Commons for organisational and individual use. CC-BY-(SA) The Share
Alike (SA) is specifically applied to derived archetypes and templates only.

---

[Sam Heard] The text may not be sufficiently clear but the intent is.  We
are drawing attention to the fact that the intent is that the SA part of the
license is only applied to derived archetypes and templates. That is, it is
a CC-BY-SA license with specific exclusion of all derivations except
archetypes and templates. This means that anyone creating a template from
archetypes cannot claim that they own it and no one else can use or copy it.
They can keep it secret. I apologise if this is not clear.

The thoughts behind the third point in the Principles of licencing are
understandable, but as stated over and over again, e.g. at...

http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Propos
al?focusedCommentId=13041696#comment-13041696 

...the SA part of CC-BY-SA won't help against copyright and patent abuse.
Only fighting possible upcoming bad patents in particular and bad patent
laws in general might save the openEHR community form patent abuse.

[Sam Heard] If this is true then the SA part of the license has no value. If
this is true then I have not heard this before.

 

A more practical way is to enforce good licencing (e.g. CC-BY) upon import
of archetypes and archetyped data in real systems and tools. That will at
the same time protect against anybody sneaking in badly licenced stuff that
is not derived from openEHR original archetypes (something that a CC-BY-SA
scheme never will be able to protect against.) 

[Sam Heard] The intent is not to stop the use of any archetypes whatsoever,
for any purpose. It is not policing. Rather , the intent is to ensure that
people cannot stop anyone using an archetype or template without any
recourse to action by others.

 

There are many other interesting things to discuss and clarify in the white
paper

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Thanks Diego

[Sam Heard]  This would be a step forward and would allow for slim and fat
systems to offer the same basic calls.

  My suggestion is for the this point
 Begin an open source software project for tools, web-based if
 possible, to author archetypes, templates and terminology reference
 sets directly interacting with the Clinical Knowledge Manager and
 equivalent repository and review tools
 
 I agree with the first part (create web-based open source tools), but
 I think that the second part should be clarified. We should define a
 basic API to access repositories, to avoid doing ad-hoc
 implementations for each one of the possible repositories

openEHR Transition: two procedural and one licensing question

[Sam Heard]

Thanks Pablo ? this is very helpful.

Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Tuesday, 6 September 2011 8:42 AM
To: openehr technical
Subject: RE: openEHR Transition: two procedural and one licensing question

 

Hi,

I think Diego's point is to change this ... directly interacting with the
Clinical Knowledge Manager and equivalent repository and review toolsto
something like ... to interact with any Clinical Knowledge Manager through
a standard API (to be defined).


-- 
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: Mon, 5 Sep 2011 21:49:01 +0100
Subject: Re: openEHR Transition: two procedural and one licensing question
From: ian.mcnic...@oceaninformatics.com
To: openehr-technical at openehr.org

Hi Diego,

I understand from Sebastian that you have been exploring the current CKM web
services.  Do you think these might form the basis for an open repository
API or do you have any other comments or alternative suggestions? 

Ian

On Monday, 5 September 2011, Sam Heard sam.heard at oceaninformatics.com
wrote:
 Thanks Diego

 [Sam Heard]  This would be a step forward and would allow for slim and fat
 systems to offer the same basic calls.

  My suggestion is for the this point
 Begin an open source software project for tools, web-based if
 possible, to author archetypes, templates and terminology reference
 sets directly interacting with the Clinical Knowledge Manager and
 equivalent repository and review tools

 I agree with the first part (create web-based open source tools), but
 I think that the second part should be clarified. We should define a
 basic API to access repositories, to avoid doing ad-hoc
 implementations for each one of the possible repositories



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


-- 
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care  www.phcsg.org


___ openEHR-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/20110906/0d940784/attachment.html

openEHR-technical Digest, Vol 49, Issue 12

[Sam Heard]

Mahdi

The ID needs to be the archetypeID not the archetype-node-ID if it is the
root node of an archetype.

Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of mahdi.asgari at gmail.com
 Sent: Saturday, 30 April 2011 6:02 PM
 To: openehr-technical at openehr.org
 Subject: RE: openEHR-technical Digest, Vol 49, Issue 12
 
 Hi dear Ian
 
 According to openEHR-technical Digest, Vol 49, Issue 12 you saied two
 bellow
 statement are correct (in scope of ADL 1.4):
 
 1-The archetype-node-id in a locatable constructed around an
 archetype
 in an archetypeslot is the archetype-node-id it gets from its own
 archetype
 (which is called in the slot).
 2-The archetype-node-id in a locatable constructed around the
 archetype calling the archetypeslot is to be ignored.
 
 I have a validation problem:
 If the archetype-node-id in a locatable constructed around an archetype
 in
 an archetypeslot is the archetype-node-id it gets from its own
 archetype,
 means at(child archetype node id) instead of at0001(slot node id)
 so how
 can I apply occurrence of slot? for example
 
 Entry[at] matches {-- Encounter
 content matches {
 allow_archetype INSTRUCTION [at0001] occurrences matches
 {0..1}
 matches {
 include
 domain_concept matches {/instruction.v1/}
 }
 allow_archetype OBSERVATION [at0002] occurrences matches
 {1..1}
 matches {
 include
 domain_concept matches {/observation.v1/}
 }
 }
 }
 
 the object may be something like this:
 content xsi:type=INSTRUCTION
 archetype_node_id=at
 .
  /content
 content xsi:type=OBSERVATION
 archetype_node_id=at
 .
  /content
 
 In the above example how I can apply occurrence for INSTRUCTION objects
 optional or just one occurrence and OBSERVATION only one occurrence
 must be
 appear.
 Or maybe we must bypass constraint defined on slots?
 What is the main constraint applied? Slot constraint or child archetype
 constraint?
 
 Thanks in advance
 
 
 
 -Original Message-
 From: openehr-technical-bounces at openehr.org
 [mailto:openehr-technical-bounces at openehr.org] On Behalf Of
 openehr-technical-request at openehr.org
 Sent: Monday, August 23, 2010 5:05 PM
 To: openehr-technical at openehr.org
 Subject: openEHR-technical Digest, Vol 49, Issue 12
 
 Send openEHR-technical mailing list submissions to
   openehr-technical at openehr.org
 
 To subscribe or unsubscribe via the World Wide Web, visit
   http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 or, via email, send a message with subject or body 'help' to
   openehr-technical-request at openehr.org
 
 You can reach the person managing the list at
   openehr-technical-owner at openehr.org
 
 When replying, please edit your Subject line so it is more specific
 than
 Re: Contents of openEHR-technical digest...
 
 
 Today's Topics:
 
1. Re: ArchetypeNodeId of an archetypeslot (Ian McNicoll)
2. Re: ArchetypeNodeId of an archetypeslot (Bert Verhees)
 
 
 --
 
 Message: 1
 Date: Mon, 23 Aug 2010 13:19:09 +0100
 From: Ian McNicoll Ian.McNicoll at oceaninformatics.com
 Subject: Re: ArchetypeNodeId of an archetypeslot
 To: For openEHR technical discussions openehr-technical at openehr.org
 Message-ID:
   AANLkTik70HRY1VVSHjUr+ufiCULjyvN=uM4q=jt5v9QD at mail.gmail.com
 Content-Type: text/plain; charset=utf-8
 
 Hi Bert,
 
 I appreciate you will be currently using ADL1.4, but in essence, by
 aggregating archetypes as you suggest, you are creating a template. ADL
 1.4
 does not define this aggregation/template behaviour, which is why I
 pointed
 you to the ADL1.5 specs, which cover both the templates and specialised
 archetypes. We, therefore do not have an official ADL1.4 answer to your
 question but your final statement is correct :
 
 The archetype-node-id in a locatable constructed around an archetype in
 an
 archetypeslot is the archetype-node-id it gets from its own archetype
 (which
 is called in the slot).
 The archetype-node-id in a locatable constructed around the archetype
 calling the archetypeslot is to be ignored.
 
 Also remember that there is no absolute requirement for a single slot
 to
 have an atnode name but Heather and I now pretty well always assign one
 routinely as it helps document the usage of the slot for downstream
 users.
 
 
 Ian
 
 Dr Ian McNicoll
 office / fax  +44(0)141 560 4657
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com
 ian at mcmi.co.uk
 
 Clinical Analyst  Ocean Informatics
 Honorary Senior Research Associate, CHIME, University College London
 openEHR
 Archetype Editorial Group Member BCS Primary 

Use of Identifiers in archetypes

[Sam Heard]

Hi

There have been a few issues with DV_IDENTIFIER - largely that all fields
are mandatory. This may mean that users puts stuff in that is not helpful.
There is also no known set of things to use at any point although this could
be expressed in a template (or archetype although this would not be
appropriate).

There is a WORKFLOW_ID on every entry that Ocean have been using to link
data around a particular workflow - this is the PLACER_ID in HL7 v2. It
allows observations, actions etc to be related to a particular instruction.

This is working well and keeps things relatively simple. Feeder_audit is a
great way to find information about feeder systems and is present in 13606
as well. It is not in the archetype (constrained) but should be visible soon
in CKM.

I would also suggest that we allow people to use the HL7/ISO datatype names
for the models to aid use and familiarity. It will be a diminished set
(openEHR compatible) but should meet all the needs of the modellers.

Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Ian McNicoll
 Sent: Wednesday, 19 January 2011 8:32 AM
 To: For openEHR technical discussions
 Subject: Re: Use of Identifiers in archetypes
 
 Hi Grahame,
 
 The concern about FEEDER_AUDIT related to its use in outgoing service
 requests e.g.  within referrals / lab requests etc. This is
 technically possible but against the intentions within the
 specifications as Thomas suggested in his eralier reply. Personally I
 would be happy to see the specifications change to allow FEEDER_AUDIT
 used in this way.
 
 Ian
 
 Dr Ian McNicoll
 office +44 (0)1536 414994
 fax +44 (0)1536 516317
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com
 
 Clinical analyst,?Ocean Informatics, UK
 openEHR Clinical Knowledge Editor www.openehr.org/knowledge
 Honorary Senior Research Associate, CHIME, UCL
 BCS Primary Health Care ?www.phcsg.org
 
 
 
 
 On 18 January 2011 20:30, Grahame Grieve grahame at kestral.com.au
 wrote:
  Hi Peter, Tom
 
  thanks
 
  Just take care to use FEEDER_AUDIT for ids generated in external
 systems,
  rather than assigned within the openEHR system, including by users
 of apps
  talking directly to the openEHR system.
 
  I'm not sure which way to parse that sentence
 
  Generally, about FEEDER_AUDIT, it's something I had missed, so I'll
 go
  and review it, but how does it manifest in the archetype editor?
 
  Ian:
 
  Using FEEDER_AUDIT was actually discussed as part of deciding how
 best
  to handle Placer and Filler Order numbers in lab tests etc . The
  problem we have is that we also need to add these identifiers to
  outgoing order /referral messages (and track those within the EHR),
  and FEEDER_AUDIT was deemed unsuitable for this purpose.
 
  because the identifiers weren't explicitly identified? Can you say
 why it
  was deemed unsuitable?
 
  thanks
  Grahame
  ___
  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

Issue with class PARTICIPATION. Should it be Locatable or Pathable?

[Sam Heard]

Hi Justinas,

 

My clinical input..

 

You are showing an impressive level of knowledge here and have hit an area
where there is still debate. There are a number of requirements:

1.  I think want to maintain the ability to add participations that are
not archetyped. It is clear that systems, wards, clinics etc will want to do
this on an ad hoc basis and formalising participations too much will not be
possible in advance.

2.  Participations have a link to a demographic entity and limited
structure beyond that. Users want a pretty simple way to say that Dr John
Brown was the assistant surgeon and Dr Karl Mitten was the Anaesthetist (or
the like). The tagged PARTY_IDENTIFIED is probably enough but the ID is
contentious. Should this be the national doctor ID? Or the ID used for this
person with the details stored elsewhere in the composition (or extract).
This needs more thought.

3.  Highly structured participations probably need to be archetyped in
the CONTEXT to ensure that you have what you need. We have used the
demographic clusters for this purpose (as they can be shared across the two
models).

 

I am keen to allow multiple instances of a node without a unique name as
these names are for the GUI and get problematic. We are moving to this
approach as it does mean that events do not need a name (they have a time
after all) and simplifies things a good deal. It does require position in
the query syntax.

 

It will be good to hear from the technologists what they see as the
solution.

 

Cheers, Sam

 

 

 

 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Justinas
Prelgauskas
Sent: Saturday, 8 January 2011 12:00 AM
To: openehr-technical at openehr.org
Subject: Issue with class PARTICIPATION. Should it be Locatable or Pathable?

 

Hello,

 

We are having some problems with Reference Model class PARTICIPATION.

We want to define an archetype of COMPOSITION type and state, that it could
have two types of participants: Doctors and Patients; At least one Doctor
and one Patient participant must be specified.

 

After we create an archetype (we use Ocean Archetype Editor v2.2) and
constrain PARTICIPATION.function using at0007 = Doctor  at0008 =
Person, we get following XML (I removed all unnecessary elements):

 

attributes xsi:type=C_MULTIPLE_ATTRIBUTE

  rm_attribute_nameparticipations/rm_attribute_name

  children xsi:type=C_COMPLEX_OBJECT

rm_type_namePARTICIPATION/rm_type_name

node_id /

attributes xsi:type=C_SINGLE_ATTRIBUTE

  rm_attribute_namefunction/rm_attribute_name

  children xsi:type=C_COMPLEX_OBJECT

rm_type_nameDV_CODED_TEXT/rm_type_name

node_id /

attributes xsi:type=C_SINGLE_ATTRIBUTE

  rm_attribute_namedefining_code/rm_attribute_name

  children xsi:type=C_CODE_PHRASE

rm_type_nameCODE_PHRASE/rm_type_name

node_id /

terminology_id

  valuelocal/value

/terminology_id

code_listat0007/code_list

  /children

/attributes

  /children

/attributes

  /children

  children xsi:type=C_COMPLEX_OBJECT

rm_type_namePARTICIPATION/rm_type_name

node_id /

attributes xsi:type=C_SINGLE_ATTRIBUTE

  rm_attribute_namefunction/rm_attribute_name

  children xsi:type=C_COMPLEX_OBJECT

rm_type_nameDV_CODED_TEXT/rm_type_name

node_id /

attributes xsi:type=C_SINGLE_ATTRIBUTE

  rm_attribute_namedefining_code/rm_attribute_name

  children xsi:type=C_CODE_PHRASE

rm_type_nameCODE_PHRASE/rm_type_name

node_id /

terminology_id

  valuelocal/value

/terminology_id

code_listat0008/code_list

  /children

/attributes

  /children

/attributes

  /children

  cardinality

is_orderedfalse/is_ordered

is_uniquefalse/is_unique

interval

  lower_includedtrue/lower_included

  lower_unboundedfalse/lower_unbounded

  upper_unboundedtrue/upper_unbounded

  lower0/lower

/interval

  /cardinality

/attributes

 

The problem with this archetype is this:

There is no node_id specified on neither of PARTICIPATION alternatives
(C_COMPLEX_OBJECTs).

Furthermore, in AOM 1.5 specification, C_MULTIPLE_ATTRIBUTE class
description (page 39) is validation rule, that sounds like this:

...VACMI: child node identification: any object node added as a child to a
container

Clinical Documents, openEHR, 13606, CDA and CCR

[Sam Heard]

 that is already captured in the openEHR
RM. The transformation may require renaming of openEHR RM attributes that
are specific for that the template as CDA documents may have different
labels that are the same thing in an EHR system (e.g. a prescription may
have a 'prescriber' whereas a document may have an 'author' where both are
the legal creator of the document).

2.  An archetype to CDA transform (and back) that labels the CDA data in
a way that it is clear which archetype this CDA data conforms to. This is
needed for each archetype and should be available on CKM.

 

The openEHR RM should also consider adding a CLUSTER to participation to
allow structured data or include participation data in the composition.
Other_participations may be the location for this with IDs that are
referenced within the composition - but this is not the planned use and will
need some consideration. Some may argue that this should be from the
demographic model but I do not think so.

 

Thoughts?

 

Cheers, Sam Heard

 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110105/9787b9ca/attachment.html

DV_QUANTITY or DV_DURATION?

[Sam Heard]

Hi

The advantage of duration is that time can be expressed in the usual way 2
months, 6 weeks, 2hr 30min, 5min 30sec etc.

The Quantity has the advantage of being able to set a fixed unit. This is
necessary sometimes and although this can be done with duration it is not
really the focus. I think both have a role.

Cheers, Sam 



 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Ian McNicoll
 Sent: Friday, 17 December 2010 11:26 PM
 To: For openEHR technical discussions
 Subject: Re: DV_QUANTITY or DV_DURATION?
 
 Hi Thomas,
 
 I think I have used DV+DURATION in all of these circumstances.. My
 impression has been that DV_QUANTITY with time property was
 deprecated.
 
 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
 
 
 
 
 On 17 December 2010 13:48, Thomas Beale
 thomas.beale at oceaninformatics.com wrote:
 
  The most usual uses are:
 
  DV_DURATION - time periods in the 'social' timescale, e.g. hours,
 days,
  weeks, months, years - e.g. pregnancy, Expected Date of Delivery,
 duration
  of migraine
  DV_QUANTITY - short time periods, being treated more mathematically,
 e.g.
  seconds or smaller, minutes and hours
 
  both can be used for computation and can be inter-converted.
 
  - thomas
 
  On 17/12/2010 13:22, Leonardo Moretti wrote:
 
  I'm wondering which is the correct use of DV_DURATION and
 DV_QUANTITY...
  When using DV_QUANTITY with property attribute 'time' (openehr::128)
 and
  when using DV_DURATION?
 
  Regards
  leo
 
 
  ___
  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-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)

[Sam Heard]

, could be to be
 interpreted as a tree. Using an ELEMENT by itself I presume would be
 the default way of expressing a what ITEM_SINGLE previously did.
 Another way is of course to always use the marker attribute and extend
 the set with single and tree.
 
 If we for some reason in the future would find the need to explicitly
 express other structures than single, list, tree and table, by
 allowing more marker values, then the change to the RM, querying,
 storage etc would be minimal, but GUIs would of course need change.
 
 Many of the methods (not attributes) in the RM are of limited use in
 implementations or parts of implementations (e.g. storage  messaging)
 that are more data-centric that object-orientation-centric, so I think
 it's generally good if some of the helper methods like the ones in
 ITEM_TABLE can be moved out from the core to some optional
 utility-package instead (if the need for having them standardised
 remains). If looking outside the item_structure package this actually
 already seems to be the case - there are pretty few methods. Good.
 
 Best regards,
 Erik Sundvall
 erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
 
 P.s. Tim, I'd be interested how these changes suggestions, in your
 wiew, relate to Keep everything as simple as possible; but no
 simpler. that you qoute on the philosophy part of
 http://www.oship.org/
 
 On Thu, Nov 11, 2010 at 00:22, Sam Heard
 sam.heard at oceaninformatics.com wrote:
  ...
  1. Restrict a cluster to a list; and
  2. Create a consistent representation of tables which have allow
 pivots as
  this is the main form required for clinical data (row headings and
 column
  headings).
 
  I believe that in the interests of existing data we made
 DATA_STRUCTURE
  inherit from CLUSTER - maintain LIST and TABLE as openEHR classes and
  deprecate TREE and SINGLE. This would keep things moving ahead. The
 data
  attribute would then be a cluster rather than an item_structure.
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Why is OpenEHR adoption so slow?

[Sam Heard]

Hi All

The adoption of all health standards is very slow; and it is universally so.
Government eHealth programs have embraced HL7v3 or CDA or openEHR or 13606 -
at great cost. Still things go slowly. The fact is that until people want a
shared logical model of the actual EHR (rather than a message or a document)
openEHR will not be centre stage.

Why have openEHR at the centre of a national program? There are a number of
reasons that are potentially persuasive.

1. The core platform as implemented does not describe clinical information.
This allows changes to clinical information to take place in the world of
archetypes (the 99% of standardisation that is yet to be carried out!). The
corollary is that only when there are enough high quality archetypes freely
available does the argument for this separation is compelling. There are
close to 300 archetypes of good quality now available and we are going to
see a rush of validation coming soon.

2. Adopting an EHR service allows applications to come and go without
losing/changing/adapting the health records. For patients, hospitals and
major providers this is a massive benefit - you can keep your health records
for a lifetime. It does, on the other hand, require enough high quality
applications to be available to provide solutions for providers. There is a
growing number - nursing, paediatric hospital, field hospital, infection
control, cancer research - but there is still some way to go.

3. The recording model in openEHR fits with the business process of
healthcare. A lot of things work out of the box from a medico-legal
perspective in a distributed environment. The coherent management of
workflow over a range of applications and services is the next step in this
process and the one that Ocean is concentrating on.

Even if the first argument is only accepted as a logical model for EHR
services, the tooling available now makes it possible to produce different
artefacts for different systems. On this basis people are becoming more
willing to invest resources in developing archetypes through open
collaboration on the internet. The second and third arguments are bringing
some institutions and software vendors along.

Seref is doing a wonderful job and Ocean has some experience in real
implementations to which Seref is party - so he does not make the same
mistakes! Where simplification is beneficial let's do it.

The reality is that openEHR proposes a massive shift in emphasis - from the
message to the EHR. More than 7000 vendors in the USA have invested in their
own data model - which they maintain. Until it is quicker, cheaper and
easier to build a system using openEHR, uptake will be slow. But I guarantee
you, the alternatives will get slower and more expensive by the day. That is
why we should continue: health information is highly complex AND 'you ain't
seen nothing yet'.

Cheers, Sam



 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Erik Sundvall
 Sent: Monday, 15 November 2010 11:29 PM
 To: For openEHR technical discussions
 Subject: Re: Why is OpenEHR adoption so slow?
 
 Hi!
 
 On Fri, Nov 5, 2010 at 10:03, Thomas Beale
 thomas.beale at oceaninformatics.com wrote:
  there are zero paid openEHR people, full-time or part-time.
 
 That is not such a useful way of looking at openEHR funding. There are
 a lot of people working with openEHR on paid time during working
 hours. They are just not funded by the openEHR foundation. This
 situation is the same for many open source projects etc.
 
 If you define openEHR people as people funded by the foundation you
 are automatically excluding most of the community from being openEHR
 people. That might not be the smartest thing to do.
 
 Too often I hear openEHR needs funding with the accompanying thought
 that the foundation itself needs a lot of money. Yes the foundation
 might need a little money for server  maintenance costs (if we don't
 want to use free services) and for trademark registrations etc. But
 the real need is working hours, not money.
 
 Certain organisational behaviours make people and companies donate
 working time, while other behaviours do the opposite. Some behaviours
 get the time donations ending up within the original project, other
 behaviours result in related projects more using and indirectly
 contributing to the project via related but organisationally
 independent projects.
 
 Many other volunteer organisations understand this difference better
 than what the openEHR foundation seems to do, at least judging from
 the few signals one can receive from the not-so-community-present
 foundation board that has nobody to formally answer to but themselves.
 In a volunteer project it can be quite OK with natural self appointed
 leaders, often the founders, but it then has to be matched with other
 attitudes or safeguards such as...
 - being very good at communicating and willing to actively explain 

openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)

[Sam Heard]

Hi All

The HISTORY class is an absolute godsend - could be a bit simpler but really
it is one of the reasons openEHR is going ahead. Once people get to use the
INSTRUCTION and ACTION classes there will be another leap of understanding.
Our recent work with the instruction index is making managing health
information in a distributed environment possible.

We have learned a lot over the past few years - but I am a practicing
clinician and the following should be read with that in mind! 

There are two things that we cannot achieve with ADL alone:

1. Restrict a cluster to a list; and
2. Create a consistent representation of tables which have allow pivots as
this is the main form required for clinical data (row headings and column
headings).

I believe that in the interests of existing data we made DATA_STRUCTURE
inherit from CLUSTER - maintain LIST and TABLE as openEHR classes and
deprecate TREE and SINGLE. This would keep things moving ahead. The data
attribute would then be a cluster rather than an item_structure.

This would respect the existing data and allow the change of archetypes over
time but existing data would remain compatible (except ITEM_SINGLE which is
not used). 

It would mean a change to the RM in the area of data_structure. I do not see
any need for Item_Structure and History to inherit from this class and I do
not believe this inheritance is used to advantage within the RM. So changing
Instruction.activity.description, Observation.History.Event.data,
Action.description and evaluation.data to cluster would be the first step.
History would be a stand alone locatable class and ITEM Structure inherit
from cluster.

Functions associated with ITEM_TREE are relevant for CLUSTER and could be
subsumed. The functions of ITEM_LIST could also be subsumed although the
return value would be ITEM (The ITEM_LIST could provide the constraint of
these functions to ELEMENT). The 'as hierarchy' feature becomes the 'items'
of CLUSTER.

ITEM_TABLE has a lot of features and no data - I believe that it needs some
added data around the pivot expression. While this may be considered only a
display feature, it is critical to the interpretation.

That is my change request and one that will align openEHR and CEN 13606 more
deeply with benefit to both. It will make CLUSTER archetypes available as
the root for some ENTRIES (what is called embedded in the Archetype Editor)
and as further down the tree in others. These will be available for CEN and
openEHR. 

There is one more thing I would advocate for: Calculation of the max and min
cardinality of the cluster and not setting it. This is problematic from the
point of view of future revision. To illustrate:

If I have one mandatory element (1..1) and four optional ones (0..1) then
people argue that I could set the cardinality of that list to 1..5. The
problem is if next week one of the optional ones becomes 0..* - quite likely
with terminologists about. Now the cardinality is wrong and we need a new
version. I would argue that we should not set the cardinality of clusters
unless we are forcing a choice between two sets - Tom has been looking at a
way to do this anyway and if that arrives I would argue that we should not
allow cardinality statements in clusters at all. They are redundant.

Cheers, Sam





Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Erik Sundvall
 Sent: Thursday, 11 November 2010 3:26 AM
 To: For openEHR technical discussions
 Subject: Re: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc
 and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
 
 Hi!
 
 On Wed, Nov 10, 2010 at 17:26, tom.seabury at nhs.net wrote:
  My simple reading of this is that what are currently trees would
 instead be
  expressed as a sparsely populated arrays - is that the point?
 
 Just to clarify it is has not already been clarified enough by others:
 Everything that is currently a tree in openEHR archetypes would most
 likely remain a tree. What would change is that the rarely used class
 ITEM_TABLE would no longer be needed. The data in an ITEM_TABLE
 already today is represented as a cluster internally.
 
 So, no, what are currently trees won't become sparsely populated
 arrays.
 
 Hope that helps.
 
 Best regards,
 Erik Sundvall
 erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
 
 P.s. to Tom: those PAINFULLY_LONG_CLASSNAME_SUGGESTIONS were only
 intended to make a point, not as a final suggestion. openEHR probably
 does not need to change anything as long as the potential confusion is
 well described in specifications and presentations. (See the post
 http://www.openehr.org/mailarchives/openehr-clinical/msg01353.html for
 details again.) If CEN/ISO still have problems with the names after
 such an explanation then one could assume that they will be the ones
 suggesting better alternatives.
 
 --- warning, irony below this 

CR for openEHR RM - Clusters and Data structures

[Sam Heard]

Dear All

 

As an involved clinician I have been thinking about advantages of using
inheritance to relate DATA_STRUCTURES and CLUSTER. This arises from two
things we have learned in clinical modelling:

1)  At almost every point where a DATA_STRUCTURE is currently specified
in the RM it would probably be inappropriate to model any structure other
than a ITEM_TREE. This is because any change to this will invalidate
existing data and we have learned that information models get more complex
with time. So the construct of DATA_STRUCTURE at the moment offers no real
value in return for the complexity it introduces as it stands at the moment.

2)  A ITEM_TABLE or ITEM_LIST 'constraint' can more usefully appear at
any point in the data - even forcing a ITEM_TREE is useful if you can see
that specialisation should always allow hierarchical structures.

 

I am suggesting that we change the model to have ITEM_STRUCTURE inherit from
CLUSTER. This would mean that ITEM_STRUCTUREs always behaved as clusters
(paths etc) but had added features. A ITEM_LIST then becomes a constraint on
a CLUSTER to only allow ELEMENTS. And ITEM_TABLE could now appear anywhere
in the data.

 

For backward compatibility it would mean that ITEM_SINGLE and its 'item'
attribute would have to be made obsolete. In fact an ITEM_LIST with
cardinality of 1 offers the same constraint capability. At the moment
ITEM_STRUCTURE and HISTORY inherit from DATA_STRUCTURE but I am not sure if
that confers any benefit as I do not think that DATA_STRUCTURE is present
anywhere in the model. Thomas may want to elucidate this aspect. It may mean
that we need a new interface with multiple inheritance in Eiffel if that is
important.

 

This does mean that openEHR is more closely aligned with CEN as well - that
is to say all data would be clusters with more attributes where ITEM_TABLE
was used and more features in software.

 

I am interested in the Techo's response to this idea.

 

Cheers, Sam

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100512/219697b8/attachment.html

Archetypes and XML-Schemas

[Sam Heard]

Hi Andrew

This is not quite correct as we are talking about constraint. The default is
what is in the RM. The three states are:
1. As in the RM - no statement
2. Required (optional in RM)
3. Prohibited (optional in RM)

Is that sensible - Sam


 -Original Message-
 From: openehr-technical-bounces at chime.ucl.ac.uk [mailto:openehr-
 technical-bounces at chime.ucl.ac.uk] On Behalf Of Andrew Patterson
 Sent: Wednesday, 12 May 2010 12:24 PM
 To: For openEHR technical discussions
 Cc: openehr-technical at openehr.org
 Subject: Re: Archetypes and XML-Schemas
 
  This is a binary constraint. For this reason we are proposing that
 existence
  is represented as an optional attribute with 2 values
  'required' and 'prohibited'.
 
 Sam, an optional attribute with 2 values actually allows 3
 states. Of course the default will map to one of the two
 values - but this does allow 2 ways of expressing the
 same concept.
 
 My two preferences for this situation (representing
 binary constraints)
 
 a) mandatory attribute with 2 values
 
 - or -
 
 b) an optional attribute with ONE possible value, and where
the absence of the value is the default.
 
 Andrew
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

How to express multiple composers for a composition with an history of events

[Sam Heard]

Hi Leonardo,

Two things. First, a composition does not relate to an encounter but rather
a recording. So you could have a number of compositions for one encounter
with the data entered by different people.

Second, each ENTRY has an information provider which can be used to
reference the source.

Third, attestations can be made on any data signing the content. This is for
non-repudiation but can be used purely for information.

To use the first two mechanisms you will have to have separate ENTRY
instances. Only the third mechanism would allow the same entry to be used
but different events to be signed by different staff.

Hope this is helpful.

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 Moretti Leonardo
 Sent: Tuesday, 13 April 2010 11:05 PM
 To: openehr-technical at openehr.org
 Subject: How to express multiple composers for a composition with an
 history of events
 
 Hi everybody,
 
 looking at Apgar score (openEHR-EHR-OBSERVATION.apgar.v1) and Barthel
 Index (openEHR-EHR-OBSERVATION.barthel.v1) archetypes in CKM
 (http://openehr.org/knowledge/), I undestand we can have several
 event
 samples of this data within the same HISTORY structure. So the same
 Barthel Index composition could contain several samples taken during an
 inpatient encounter.
 But in this way, how can we indicate that different sample are be taken
 by different doctors/nurses, if we can specificy the composer just at
 composition level and not at event level?
 
 Regards
 leo
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Term bindings in archetypes and templates

[Sam Heard]

Hi,

This is an interesting discussion. I think we need to keep a sense of
purpose here in what we are doing. We need to understand that the complexity
of biomedicine is probably unsurpassed and the language of health
professionals is a way of dealing with this. It has historical roots which
allows people to drill down when appropriate. The paper by Werner and Barry
on malaria illustrates the difficulties. So we will find, if we look hard
enough, that there are massive imperfections in what clinicians record but
these imperfections are generally understood by those that need to know
about them.

I remember a story about a medical teacher when I was young asking a rather
impertinent student what they knew about the cause of rheumatoid arthritis.
He said Nothing. And then he asked the student And what do I know about
the cause? He again said Nothing. The teacher nodded and added But don't
underestimate the gap between what you know about the cause of rheumatoid
arthritis and what I know.

We don't call rheumatoid arthritis idiopathic arthritis because we have
accepted the syndrome and its histological features. We know the prognosis
and outcomes in many situations. Patient's would like to know why - but we
can't tell them. Malaria is actually four diseases - two of which actually
are rather different from the other two. Pneumonia, from the perspective of
causation, is actually 100s of diseases all with a similar pathology. When I
read the paper on malaria by the ontology guys I learned a lot. I have
diagnosed and treated malaria quite a few times in my life but did not know
some features of the life cycle of the plasmodium and the features that
Werner and Barry are describing at times are not of clinical significance.

So where does ontology get in the way of good health care? I would suggest
it is when there is no 'drill down'; that complexity is presented as a flat
knowledge space. Deep knowledge in clinical practice, what is needed to
provide the best care, is not necessarily detailed knowledge - the latter is
usually the preserve of bioscientists and clinicians researching an area.
They might come back to us with more detail that alters the knowledge
required to provide the best care. It is then that deep knowledge shifts.
More detailed knowledge does not necessary lead to more complex deep
knowledge. Asthma is a good example. Treatment used to be a nightmare but as
we have learned more it is really quite simple to manage.

So I just want to challenge the approach of linking to ontologies. I would
like to propose a simplification. If we take the archetypes as the purest
expression available of what clinicians want (or are able) to record then we
have something. We can organise and classify these in future to make them
very available. CKM has started that process and it will get more
sophisticated.

The task then for term_bindings is to link points in archetypes to
terminology so that other people can understand from that perspective what
we are talking about. I would argue that there are two approaches. First is
to find a term in a terminology that says exactly what the archetype is
recording. The second approach is to find the observable entity that is
being recorded.

It becomes absurd at one level to think about the things that you might
describe:
 - the notion of the thing that might be observed (blood CO2 level)
 - the procedure for measuring it (which might be complex) and everything
about that
 - the recording of the value of the thing that has been observed and any
confounding factors
 - the actual value of the thing observed.
The archetype actually records many of these things as well as the value. A
pure ontology for such a thing will get massively complex. Do we have the
procedure for measuring the confounding factors, the recording of the
procedures for measuring them, the actual value of these etc. If we are
measuring the blood gas there may be may features of the measuring process
that we want to record - do we have observable entities for all of these,
procedures for measuring them and recording and values.

I hope you can see where we are going here. We have to stay anchored in what
is useful and effective clinical practice. The fractal nature of this is
becoming clear and we will see just how fractal things get when we start
recording genetic features of cancers (and people).

I think we should start by working purely with term_bindings for the
observable entity that is expressed in the archetype - as a whole and then
for each entry in the data section of the observation if that is helpful.

I find this a very fruitful area of enquiry and I do not want to stifle it
at all - just to point out that what might appear imperfections often are
important kludges that are shared widely and work in real practice.

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 Fabrice Camous
 Sent: 

Clarified semantics of CONTRIBUTION.audit.change_type

[Sam Heard]

Hi

The issue is that AUDIT_DETAILS is used for commit and for individual items.
The vocabulary is designed for revision of COMPOSITIONS and not really for
ATTESTATION (when there is no change) or CONTRIBUTION which may have
multiple COMPOSITIONS.

You approach seems fine but it does show that multiple composition changes
in a single contribution has not been a feature of systems to this point.

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: Monday, 15 February 2010 9:40 PM
 To: For openEHR technical discussions
 Subject: Clarified semantics of CONTRIBUTION.audit.change_type
 
 Hi!
 
 I just want to share a (to me) clarifying implementation discussion to
 the list so that it does not get lost in cyberspace :-)
 
 I wondered if e.g. the contribution 1 in fig 25 on
 http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output
 /versioning.html#1126708
 really was possible to record as single contribution or if it needed
 two contributions (with identical timestamps) but different
 AUDIT_DETAILS.change_type (one for creation and one for modification).
 I had a chat (attached below) with Tom Beale regarding this.
 
 I had somehow gotten the impression that all AUDIT_DETAILs of
 versioned objects belonging to a single contribution should be
 identical. This is not the case, instead e.g. the
 VERSIONT.commit_audit.change_type can be different for the different
 objects within the same contribution.
 
 The remaining question is then what type to select for
 CONTRIBUTION.audit.change_type when the related
 VERSIONT.commit_audit.change_type attributes are mixed in a
 situation like in fig 25. It seems that the semantics of
 CONTRIBUTION.audit.change_type is not crystal clear and needs to be
 clarified in the specs. In the mean time our implementation will set
 CONTRIBUTION.audit.change_type to unknown for mixed stuff and set it
 to deleted only if all changes of the commit are deletions (and
 creation if all are creations etc).  Any comments regarding this
 solution?
 
 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.)
 
 - - -
 
 Shortened and somewhat spelling-corrected chat between Erik Sundvall
 and Thomas Beale 15:th of February 2010:
 
 ES: Are the contributions 1  3 in fig 25 on
 http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output
 /versioning.html#1126708
 really possible to record as a single contribution or do they need two
 contributions (with identical timestamps) but different
 AUDIT_DETAILS.change_type (one for creation and one for modification)?
 
 TB: the implication in that diagram is that CIx and CIy happened at
 difrerent times, for example CIx is due to a test result being added
 to the EHR and CIy is the next patient encounter where the physician
 modifies the plan (CId), the medications (CIb) and also there is the
 encounter note itself (CIy)
  sorry - just realised you said 1  3
  but the principle is the same
 
 ES: I mean within contrib 1: CIw and CIa' are in the same contrib
  ...but are of different types.
 
 TB: yes
  CIw is an encounter note COMPOSITION
  CIa' is something like a problem list COMPOSITION
 
 ES: Yes I understand that part already :)
  AUDIT_DETAILS.change_type perhaps instead should be
 VERSIONT.change_type
 
 TB: well VERSION and AUDIT_DETAILS is 1:1
  (apart from additional attestations which might occur)
 
 ES: Do you mean that the AUDIT_DETAILS can be different for different
 VERSIONs in the same contrib?
 
 TB: sure
  every VERSION has its own AUDIT_DETAILS
  AUDIT_DETAILS is not any kind of shared object
  http://www.openehr.org/uml/release-
 1.0.1/Browsable/_9_0_76d0249_1109326589721_134411_997Report.html
 
 ES: I thought it was supposed to have exactly equal content for all
 versions changed in a contribution.
  So what is the change_type on CONTRIBUTION.audit for a mixed
 contrib?
 
 TB: just something like 'change'
  or 'update'
 
 ES: (I meant CONTRIBUTION.audit.change_type)
 
 TB: yes
 
 ES: so if we do both creation and modification in the  contrib we'll
 arbitrary pick one of them?
 
 TB: there is not 100% clean way to map say 3 individual different
 types of change (say and addition, a modification and an error
 correction) to anything more specific on the CONTRIBUTION
  well the meaning should be taken to be: what was the change to the
 EHR as a whole?
  it is usually either a creation (only new content), modification
 (mixed changes) or could be a deletion
  this attribute on the CONTRIBUTION audit trail is not that important
  it is just like in SVN or any other VC system
  in a way, all change sets are just 'modifications'
  but it could be useful is a lot of new content were being added in
 
 ES: Well you don't have change_type in svn on the commit level its on
 the 

data types and structures questions

[Sam Heard]

No ? I did that in the second email. Sam

 

From: openehr-technical-bounces at chime.ucl.ac.uk 
[mailto:openehr-technical-boun...@chime.ucl.ac.uk] On Behalf Of Masoumeh Seydi
Sent: 22 December 2009 15:04
To: For openEHR technical discussions
Subject: RE: data types and structures questions

 


Hi Sam

Thanks for the reply. Are you pointing the interval classes?

Regards
Masoumeh

  _  



--- On Sun, 12/20/09, Sam Heard sam.heard at oceaninformatics.com wrote:


From: Sam Heard sam.he...@oceaninformatics.com
Subject: RE: data types and structures questions
To: openehr-technical at openehr.org
Date: Sunday, December 20, 2009, 9:38 PM

Hi Masoumeh

 

There is a difficulty that arises with data that is not completely entered and 
being able to save it in the repository in that state. One could argue that it 
should all be entirely consistent, but it does mean that it is not so easy to 
use in reality. I am always arguing for a degree of flexibility in the specs ? 
you are free to put it in your software if you want it like that.

 

Cheers, Sam

 

From: openehr-technical-bounces at chime.ucl.ac.uk 
[mailto:openehr-technical-boun...@chime.ucl.ac.uk] On Behalf Of Masoumeh Seydi
Sent: 21 December 2009 14:53
To: openehr-technical at openehr.org
Subject: data types and structures questions

 


Hi All,
 I've got some questions about data types and structures. I was wondering if 
someone could help me.

1. Why an item_single can,t be empty but other structures may be. I mean 
'items attribute's cardinality in item_single is 1..1 (and this is logical. 
coz' an item_single without element is meanless). But in other structures, the 
cardinality of items attribute is 0..1. What's the point of having an empty 
list or tree or table (without ant item in it)?

2. What's the difference between CLUSTER and ITEM_TREE? Both can have CLUSTERs 
and ELEMENTs. And why in all structures in CKM, there is a Data branch shown in 
archetype mindmap but in cluster archetypes, there is a Items branch?

3. There is an  Interval intrface containing lower and upper attributes. Other 
intervals like IntervalOfReal, IntervalofDate, IntervalofDateTime, 
IntervalofTime and IntervalofDuration with lower and upper attributes in xsd 
file in the site. My question is, why there is not an Interval class that 
contains an attribute for declaring the type of interval and so get rid of 
other interval classes for every type?

Thanks in advance
Masoumeh

 


-Inline Attachment Follows-

___
openEHR-technical mailing list
openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical 
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/20091222/de28aeb1/attachment.html

data types and structures questions

[Sam Heard]

Hi Masoumeh

 

There is a difficulty that arises with data that is not completely entered
and being able to save it in the repository in that state. One could argue
that it should all be entirely consistent, but it does mean that it is not
so easy to use in reality. I am always arguing for a degree of flexibility
in the specs - you are free to put it in your software if you want it like
that.

 

Cheers, Sam

 

From: openehr-technical-boun...@chime.ucl.ac.uk
[mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Masoumeh
Seydi
Sent: 21 December 2009 14:53
To: openehr-technical at openehr.org
Subject: data types and structures questions

 


Hi All,
 I've got some questions about data types and structures. I was wondering if
someone could help me.

1. Why an item_single can,t be empty but other structures may be. I mean
'items attribute's cardinality in item_single is 1..1 (and this is logical.
coz' an item_single without element is meanless). But in other structures,
the cardinality of items attribute is 0..1. What's the point of having an
empty list or tree or table (without ant item in it)?

2. What's the difference between CLUSTER and ITEM_TREE? Both can have
CLUSTERs and ELEMENTs. And why in all structures in CKM, there is a Data
branch shown in archetype mindmap but in cluster archetypes, there is a
Items branch?

3. There is an  Interval intrface containing lower and upper attributes.
Other intervals like IntervalOfReal, IntervalofDate, IntervalofDateTime,
IntervalofTime and IntervalofDuration with lower and upper attributes in xsd
file in the site. My question is, why there is not an Interval class that
contains an attribute for declaring the type of interval and so get rid of
other interval classes for every type?

Thanks in advance
Masoumeh



 

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

openEHR community on Google Wave

[Sam Heard]

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

Why ISM_TRANSITION of an ACTION is mandatory?

[Sam Heard]

Hi Pablo

The resulting state of the activity (even if there is no instruction) needs
to be recorded for information to work in a distributed environment. When
you record an action the computer needs to know whether it is complete or
not in relation to any instruction (recorded or not). If you are simply
recording information you can put the state (which is the only mandatory
feature of the IM_TRANSITION) to Completed (openEHR code). As you move into
an EHR that is supporting workflow or is distributed you will see that a
medication administration will usually leave the instruction in an active
state (unless it is a single administration or the last dose). 

 

It enables recording of things like Medications ceased in hospital and the
state of these medication actions will be 'aborted' or 'completed'. You can
also suspend something etc.

 

Hope this helps.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: 19 November 2009 02:17
To: openehr technical
Subject: Why ISM_TRANSITION of an ACTION is mandatory?

 

Hi,

 

In the specs I see that ACTION has a mandatory relationship to
ISM_TRANSITION.

In my project I only use the description field of ACTION to record
information about the ACTION and I don't have information to fill the
ISM_TRANSITION.

 

My question is: why the ISM_TRANSITION of the ACTION is mandatory instead of
optional?

 

Thank you,

Pablo.

 

  _  

Windows Live: Friends get your Flickr, Yelp, and Digg updates when they
e-mail
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so
cial-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010
  you.

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

MedInfo 2010

[Sam Heard]

No private activity that I know of - Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Tim Cook
 Sent: 17 November 2009 14:43
 To: For openEHR technical discussions
 Subject: MedInfo 2010
 
 No News lately on the conecctathon.
 
 Is this still going on in private email sessions as it was before as I
 complained about?
 
 Or has it just been dropped completely since Sinji submitted his
 documents?
 
 --Tim
 
 
 --
 ***
 Timothy Cook, MSc
 
 LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
 Skype ID == (upon request)
 Academic.Edu Profile: http://uff.academia.edu/TimothyCook
 
 You may get my Public GPG key from  popular keyservers or
 from this link http://timothywayne.cook.googlepages.com/home

CKM Icons

[Sam Heard]

There was a page on a previous site for this - the archetype list had a link
to it. Thomas may know where that is gone?

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Lisa Thurston
Sent: Thursday, 22 October 2009 10:57 AM
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/4d35bcb9/attachment.html

License and copyright of archetypes

[Sam Heard]

Hi Erik,

On the licensing front, I was taken by some of the issues that Richard
raised and the concern I was expressing was the possibility of people
claiming that a particular template was their design - a group of archetypes
and then creating a form based on that. This looked particularly problematic
for clinical users from my perspective. SA seems to offer some protection
for that scenario. I think you are focussing of the users in the traditional
software sense (a very important group if you want uptake) and not the
clinicians and other expert users who create the archetypes and who I want
to be the leaders in both creation and use.

Your arguments for not using SA are well put. I do not want to force people
to use openEHR Foundation archetypes - we all want the best ones to be out
there in use. If, as you say, a commercial effort created the best set and
everyone started using it, then that will be the interoperability space.

At the moment archetypes are freely available. The idea here is to get the
best possible license to help the develop the sort of community activity
that is what we want to see. BY alone is clearly a choice, SA adds a major
condition that we need to consider carefully.

Thanks for your challenging response. 

Regarding CKM. I sense that you would prefer it was open source and that is
where I started as well. Ocean worked on that basis with Central Queensland
University for 3 years and had an academic team using the usual stack
(mySQL, Apache etc) and just couldn't get there. We chose to use a closed
source asset management engine from a small company in Australia to get
something working and I believe our team, led by Sebastian, Heather and Ian,
have created something wonderful. It might be that there will be open source
tools that do this job in the future but I suspect these will flourish in
the commercial sector for the time being (Arcitecta's clients are largely
research institutes and universities!).

It would be good to have a list of interfaces for CKM people would like from
this service. You can look in the Archetype Editor for some specs
immediately as this pulls web-based files from CKM. I will ask Sebastian to
put the interfaces on the openEHR wiki. The things you can do already:
1. Pull down all the archetypes in a zip file.
2. Get a list of archetypes as a web service and download any you want.

Any refinements of the interface people would like to have, put it on the
list or send it to Sebastian.

The platform CKM is running on is Linux and Java (Could be Windows Server)
with this component in the middle. We should have a plug-in framework going
shortly as this is basically how the underlying engine operates anyway.

Cheers, Sam


 -Original Message-
 From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical-
 bounces at openehr.org] On Behalf Of Erik Sundvall
 Sent: Tuesday, 13 October 2009 8:43 PM
 To: For openEHR clinical discussions
 Cc: For openEHR technical discussions
 Subject: Re: License and copyright of archetypes
 
 Hi Sam!
 
 On Tue, Oct 13, 2009 at 01:04, Sam Heard
 sam.heard at oceaninformatics.com wrote:
  Richard has raised the issue of people copyrighting forms and other
 derived
  works based on archetypes and perhaps claiming these cannot be
 copied. This
  seems to be an argument in favour of SA...
 
 I'm not sure I understand your reasoning.
 
 1. It seems to me that previously when you argued for Share Alike (SA)
 you said that derivative  works (like GUIs) that were not archetypes
 should not be seen by the foundation as derivative works  covered by
 the SA-requirement. (It still remains to be detailed if/how such a
 position by the foundation should be formalised.)
 
 2. Now it sounds like you say that forms based on archetypes really
 should be considered derivative works and thus need to be released
 under SA too. Somehow you seem confident that this would solve more
 potential copyright issues than it would create.
 
 Don't you find the views 1  2 conflicting? Could you also detail how
 SA (in 2 above) would stop copy-fights in this setting, is it by
 disallowing all archetype based systems  that are not published under
 a SA-license, leaving only open source solutions as permitted to use
 openEHR-hosted archetypes? (Since I like to use and create open source
 I would find this interesting, but I doubt it would be realistic in
 today's health care setting :-))
 
   If you select CC-BY you can still require that any specialised or
   adapted archetypes _hosted_ by openEHR should be free under CC-BY.
 
  Well, what if the specialised archetype is hosted in Brazil for
 instance.
  What if you receive data from there?
 
 I assume you don't have a certain issue with projects based in Brazil
 (or do you?) and that you instead mean something like:
 
 What if you receive data from a stupid organisation that wants to
 share data with you and does not understand that they need to release
 the related archetypes under a licence

Modeling reference ranges

[Sam Heard]

Hi Pablo

 

The issue is that you do not see the reference model attributes in the
archetype editor. A Quantity data type has a normal range and other
reference ranges built in.

We do not set the reference ranges in archetypes as these vary and
archetypes are the absolute statement about things (what could possibly be
true ever, anywhere).

 

So it is in the form or data that you will get access to the reference
range. You could set it in a template (not possible in our tools as yet).
Generally the reference ranges come with the results from the lab or a
dynamic depending on gender, age etc.

 

I hope this is helpful - have a look at the data type specs for
clarification. The UML is at:

http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_110959933787
7_94556_1510Report.html

 

You will see an optional normal_range and 0..* other reference ranges as
part of a root abstract class DV_ORDERED

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Tuesday, 13 October 2009 8:02 AM
To: openehr-clinical at openehr.org; openehr-technical at openehr.org
Subject: Modeling reference ranges

 

Hi,

I'm playing around with archetypes trying to model an observation and its
reference ranges,
I mean something like blood pressure and some range to define what is
hypertension, but
I can't found an archetype that defines a reference range for an
observation.

Any one has experience in modeling something like this? 
An archetype is the correct place to define a reference range for an
observation value?
Any ideas?


Thak you!

Cheers,
Pablo Pazos Gutierrez



  _  

Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so
cial-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091013/26ccfa3a/attachment.html

ACME terminology

[Sam Heard]

I asked Koray - no other source known. Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Soheil Hassas Yeganeh
 Sent: Thursday, 27 August 2009 5:16 PM
 To: For openEHR technical discussions
 Subject: ACME terminology
 
 Hi There,
 
 Is there any other source instead of down http://free.terminology.org/
 site to search the ACME terms?
 
 Bests,
 Soheil
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Concept Overload Caution

[Sam Heard]

Hi everyone

There are a lot of technical people who have volunteered as reviewers on CKM
and we have had major input from a number of them. There will be more issues
that arise when we have the first set of archetypes for publication to
ensure consistency.

There is no doubt that we all benefit from people speaking up about what
their systems do and why. This helps ensure archetypes are suitable to
support existing systems.

Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Stef Verlinden
 Sent: Tuesday, 23 June 2009 4:02 PM
 To: For openEHR technical discussions
 Subject: Re: Concept Overload Caution
 
 Hi Heath,
 
 I complety agree with you. Let's all do what we're best at. What I
 would like to add to your proposal is some feedback (both ways) so
 doctors and technicians can learn from eachother. Rather than de-
 empowering the one or the other I think we should team up to create a
 properly working system that really adds value for the citizens/
 patient who are the subject of this all.
 
 Also as I clinician I really would like an understandable (at
 technical lay-mans level) manual with clear examples who things can
 work and why some solutions shoudl be avoided. Maybe some best-
 practices of whatever you like to call that
 
 Cheers,
 
 Stef
 
 Op 23 jun 2009, om 02:15 heeft Heath Frankel het volgende geschreven:
 
  Hi Tim,
  Thank you for your post, I complete agree.  Like you I am not a
  clinician
  and feel that I am rocking the establishment of openEHR and the
  principles
  of Archetypes by saying this, but I strongly believe that we need to
  have a
  technical review process of archetypes before they are published.
  What I am
  looking to review is not related to the clinical content, but the
  patterns
  used to represent that clinical content.  In particular, I would
  looking to
  ensure that we have single concept representation, loose coupling,
  reusability, appropriate use of specialisation, and most importantly
 I
  believe, appropriate structures to support querying.  These are all
  good
  object-oriented (or general software) design principles that
  technicians are
  trained to be better at then clinicians.
 
  As part of the archetype governance and publishing process, I would
  like to
  see a technical review process.
 
  I realise I am writing to a group of technicians on this list and
  this is
  probably a topic for the clinical list, but I think there probably
 are
  enough clinicians on this technical list to knock me around if they
  feel
  that I am rocking it too hard.
 
  Please understand that I not trying to re-empower the technician, I
 am
  simply looking for good quality knowledge artefacts and believe this
 a
  process that is missing in the current archetype development process.
 
  Regards
 
  Heath
 
  -Original Message-
  From: openehr-technical-bounces at openehr.org [mailto:openehr-
  technical-
  bounces at openehr.org] On Behalf Of Tim Cook
  Sent: Wednesday, 3 June 2009 9:59 AM
  To: For openEHR technical discussions
  Subject: Concept Overload Caution
 
  Hi All,
 
  The past 3 or 4 subjects on this list takes me back to conversations
  that we had before (maybe several years ago?) when we were
 discussing
  slots and links.  Maybe they were here maybe they were on the ARB
  list.
  I do not recall now.
 
  But my feeling in both of these areas are that there is a tendency
  for
  archetype developers to create archetypes that are more than one
  clinical concept.  IIRC, that is about the time that templates were
  being thought of/designed to alleviate the pressure on archetypes to
  serve everyone, everywhere.
 
  As Heath has just mentioned, templates are the better place for this
  type of grouping.  They tend to provide that ability to be more
  localized.  Remember that when you are creating or reusing
 archetypes
  that they should be universally reusable.  If they are not, then
 they
  do not meet the basic requirement of being a single clinical
 concept.
  This is fundamental to openEHR being future proof.
 
  The misuse of slots and probably any use of links in a particular
  archetype; IMHO is a very bad thing and will lead us down the road
  that
  we see with data model centric systems as opposed to our information
  model.
 
  While I am not a clinician nor a lab tech I do ask those of you
  creating archetypes to review the fundamental principles of
  archetypes
  and templates.  Then think twice before publishing an artifact.
 
  From what I am reading I think that there is becoming a tendency to
  put
  too much runtime functionality into what is supposed to be singular
  data items.
 
  My 2 cents/pence/centavos
 
  --Tim
 
 
 
 
 
  --
  Timothy Cook, MSc
  Health Informatics Research  Development Services LinkedIn
  Profile:http://www.linkedin.com/in/timothywaynecook
  Skype ID == timothy.cook
  

distributed development, governance and artefact identification for openEHR

[Sam Heard]

Hi Tom,

This is a good document - thanks. I have posted this to the clinical list as
well.
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/di
st_dev_model.pdf


My comments:

Page 11:

Current text:
Archetypes based on different classes from the same information model to
have the
same name, e.g. An archetype for 'vital signs' headings based on the SECTION
class, and
a 'vital signs' archetype based on OBSERVATION.

Comment:
I believe there will be archetypes for sections and entry that have the same
name but this is not a good example. The entries for vital signs are BP,
Pulse etc. I think it would be better to just raise the problem or get an
example. The nearest one I can think of is a plural form - e.g: Problems
(Section) and Problem (Entry).

Page 16:

Current text:
Also in common with software, there is a strong interest among archetype and
template users in one
or a few high-level shared libraries of high-quality artefacts rather than
scattered development with
poor quality control. In an ideal world, there might be only a single
repository, or a purely hierarchical
set of repositories. However, we know from experience with software
development that this is
extremely unlikely. Each organisation initially starts out with its own
point of view, timelines and priorities.
If a coherent ecosystem of cooperating repositories, or a single
international repository were
ever to exist, it would be as an emergent result of collaboration among
initially separate authoring
groups, rather than being established at the outset.

Comment:

With my software hat on I concur with your sentiment. The reality is that it
is likely to be the clinical colleges and other stakeholders outside the
software domain that produce the authoritative archetypes that are sought
after. I have no doubt that there will be both entropic and negentropic
forces. I believe that the lowest energy state is so profoundly associated
with collaborative work in this area that we are unlikely to see many
competing efforts. This is for many reasons including:
* There are many choices involved in developing archetypes - each has
implications for other archetypes that have to be developed and maintained,
translated etc
* Clinicians are interested in alignment of recording around best practice
and providing suitable flexibility - this is best done within one or a very
small number of archetypes for a given clinical concept
* Interoperability will be maximised with collaboration around the
development of archetypes and vendors will have a much smaller footprint to
manage
* The cost of creating competing sets of archetypes is massive and probably
not sustainable
* The number of clinicians and technical people in a position to contribute
is not high considering the work required
* Structuring clinical information is more fractal than orthogonal in
nature. Consensus provides a means of getting to grips with the issues and
managing complexity

In essence I am counselling everyone to see the centralised hierarchy of
repositories as infinitely more useful than the software model of go and do,
try, build and lets sort the differences in the future. I guess I am
proposing that archetypes are a lot closer to terminology than software from
a clinical perspective.

Current text:

Other national and institutional repositories are likely to come
online from 2009 onward. This trend appears to be similar to the emergence
of large-scale open
source projects.

The collaborative nature is similar. I hope that the national repositories
will be used more to organise comments and development of archetypes for the
collective effort in these early days than starting out on their own. In the
end I hope the national repositories will be where the releases of largely
international artefacts (with local specialisations) will be managed. Some
archetypes for national or local use will also be developed but these will
be edge cases. I guess I would see archetypes as the operating system of
clinical interoperability if I were to use the technical analogy.

Current text:

Based on the above considerations, the 'modern' model of software
development is
assumed to provide a suitable paradigm for openEHR knowledge artefact
development,
with emphasis on collaborative development of one or a small number of
well-known artefact
repositories.

I therefore do not agree with this statement. It may appear realistic but I
do not think it is sustainable nor to be encouraged. I am interested in what
other people think.

It is really an important consideration. Terminology also could be organised
primarily by country (or even regionally) and then at the core when people
agree on things. If the clinical leaders in the openEHR community agree with
me that we should really work with the centralised model it does not greatly
influence the technical issues in this paper but it does mean we can work
with the assumption that everyone will see a central authoritative source
and 

distributed development, governance and artefact identification for openEHR

[Sam Heard]

Hi Tom
Another very thoughtful document. I have been involved to some degree in the
discussion of this area over the years as have many others prior to this
draft release.
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/di
st_dev_model.pdf

This document suggests approaches that need very careful consideration and
at present I do not support the direction of this document - specifically in
the changes proposed. It is important that the community consider the
implications for clinical interoperability etc. This document has being
released to the community prior to careful consideration by the ARB to gauge
the views of implementers and clinicians. It will be difficult for many to
understand the implications but I want to raise some of my concerns so
people have an insight into the implications.

Page 5:

Current text:
1.4 Changes proposed in this document:
augmented form of ARCHETYPE_ID to include organisational / package
namespace, e.g.
org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v1
. concept name section of archetype identifiers (middle part of
ARCHETYPE_ID) now relaxed
to no longer require structure based on specialisation parents, e.g.
'problem-diagnosis' can
now just be 'diagnosis', or any name preferred by designers;
. addition of commit_id sub-section archetype description section;
. addition of id_history sub-section to description section, e.g.
id_history = se.skl.epj::openEHR-EHR-EVALUATION.problem.v1

This document when taken in combination with the distributed development
model raise the stakes for participants. The outcome is the promise of the
ability to interoperate from a knowledge artefact point of view but I have
doubts whether the proposed changes will support clinical interoperability.
I understand the wish of technical people to produce artefacts wherever and
whenever they like (just as terminologists do) but I would propose that we
have to manage complexity as well. In a world that is immensely complex
already (clinical systems) we may have to sacrifice some possibilities to
ensure we can perform the sort of functions people seek from a standard EHR
architecture.

I would like to add the requirements that are fundamental from my
perspective so that the community can raise these:

1. Primacy of openEHR: I would propose that we need a hierarchy of
authority. Although openEHR artefacts are presently managed within the
Foundation it is possible that the governance will move to a more
authoritative organisation in the near future. That said, I believe that
archetypes released by the openEHR Foundation should not be identified
specially (i.e. no name space). This means that openEHR becomes the default
namespace for archetypes and begins to provide a hierarchy of authority that
I think is so important in this space. One might argue that anyone can
produce archetypes with no namespace - but really anyone can produce
anything with any namespace so that is not sufficient.

2. Archetype IDs
How archetypes are identified in the universe is of no great concern to me.
I am happy to accept that people may want to give them arbitrary names and
live with complexity from an archetype management point of view. What I am
concerned about is how they are identified in data. And I do not want this
to be any more complicated than is required to support the vision we have
for openEHR. I am happy that we may need to extend this at some point but we
have seen very successful extensions of many identifiers as systems grow
(IP4-ip6, Ascii - UTF-8). I understand the technical vision - anyone can
do anything and we will be able to sort out what is going on - but I believe
we have to keep pushing for things to be right for where we are up to.

In data the model is known - therefore the openEHR-EHR is redundant in an
EHR implementation. The namespace of the archetype is not.

In data, in XML expression of openEHR data, the archetype iD Class name and
concept part provide a means of returning the data without knowledge of the
archetype. An openEHR repository can be fully implemented, use AQL etc
without any knowledge of archetypes whatsoever. The reason for this is that
the archetype Ids are used in queries, and specialisations can be found
without reference to any archetypes based on the ID. This is a fundamental
benefit for implementers and losing this will require a considerably more
complex engine with, potentially, access to every archetype ID in the world.
This is not useful.

So my fundamental requirement is, in openEHR systems, to be able to query
for specialisations without the need to go to an archetype knowledgebase
(which will by definition be incomplete).

Page 17:

Current text:
As a general principle, for a given archetype used to
create data (e.g. an openEHR OBSERVATION object), the following archetypes
could be used for querying:
. the same archetype, i.e. Exact same version, revision  commit;
. any previous revision of the same archetype;
. any of the specialisation 

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

[Sam Heard]

Hi All

 

I think I have said it before but I think we need to see this managed at the
publication level. CKM currently stores translations as distinct assets.
This has a number of advantages:

1)  Translations can be added, reviewed, accredited asynchronously for
the same archetype

2)  Translations can be updated independently of revisions

3)  Archetypes can be downloaded with the languages required

 

Cheers, Sam

 

 

 

From: openehr-implementers-boun...@openehr.org
[mailto:openehr-implementers-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Monday, 4 May 2009 9:02 PM
To: For openEHR implementation discussions
Cc: For openEHR technical discussions
Subject: Re: [Fwd: [JIRA] Created: (SPEC-302) Translations embedded in the
ADL are not efficient and should instead use 'gettext' catalogs.]

 

Tim Cook wrote: 

On Thu, 2009-04-30 at 22:03 +1000, Thomas Beale wrote:
  

It is clearly true that with a number of translations the archetype will
grow
bigger, and initially (some years ago) I thought separate files might be
better as well. But I really wonder if it makes any difference in the end -
since, in generating the 'operational' (aka 'flat') form of an archetype
that
is for end use, the languages required (which might still be more than one)
can be retained, and the others filtered out. I don't think gettext would
deal
with this properly - the idea that an artefact can have more than one
language
active.


 
I can only refer you to the bazillions of applications that use
gettext. Browsers and GUI widgets everywhere are designed, expecting
gettext catalogs. Not using gettext means that every implementation has
to develop their own filtering mechanisms; in place of reuse of proven
existing technology.  OR; you could choose to develop an openEHR
filtering specification.  Then develop browser interfaces and widget
interfaces to match. 
  


but my question was: if we want an archetype to retain 2 languages, e.g.
english and spanish, out of the (say) dozen available translations, can
gettext be made to do that?




 
  

The other good thing about the current format (which will eventually migrate
to pure dADL+cADL) is that it is a direct object serialisation, and can be
deserialised straight into in-memory objects (Hash tables in the case of the
translations).


 
H, sorry, I don't get the point here.  Seems to me you are saying
that you pull all translations into memory.  Instead of letting the
application decide which one it wants.
  


well that is the default; but depending on what 'application' we are talking
about, this is quite likely what is wanted - e.g. if it is an archetype
design tool that also managed translations. But I take your point - we
probably should make it so that dADL can ignore some parts of an input file.





 
  

Anyway, I think that we need to carefully look at the requirements on this
one, before leaping to a solution...


 
Of course.  That is why I suggested targeting the 2.0 version.  There is
a good chance that there will be knock on effects (good or bad) to the
RM (AuthoredResource, et.al.) as well.
 
 
I'd like to go back to a very basic question I have.  What is the use of
having the original language as (a specific) part of the archetype if it
isn't meant to be the validation language?  Seems to me that it is the
expression of the original author for the  construction of the
archetype.  Translations are a convenience for everyone else. 
  


Not sure I understand the question Tim - do you mean: is the original
language used in validation? There are very few things that are
linguistically dependent in the validation operation - only where regular
expression constraints are usedcan't think of any others off hand. The
linguistic elements of the ontology section get used on the UI of course,
and in documents, but that is for humans, not computing.

- thomas

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

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

[Sam Heard]

Hi Tim

I am keen, as some others have said, that CKM manages this with users being
able to get as many translations as they need when they download the
archetype. The advantage with the approach is that you do not need the
source language to translate using the archetype so you do not need to keep
languages not used locally.

It does rely on CKM but allows full language archetypes for repositories
whenever they are sought.

Sebastian has already got to a point in CKM where languages are stored
separately and languages can be added, reviewed and approved independently.

Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Tim Cook
 Sent: Wednesday, 29 April 2009 6:23 AM
 To: For openEHR technical discussions; For openEHR implementation
 discussions
 Subject: [Fwd: [JIRA] Created: (SPEC-302) Translations embedded in the
 ADL are not efficient and should instead use 'gettext' catalogs.]
 
 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?
 
 
 --
 Timothy Cook, MSc
 Health Informatics Research  Development Services LinkedIn
 Profile:http://www.linkedin.com/in/timothywaynecook
 Skype ID == timothy.cook
 **
 *You may get my Public GPG key from  popular keyservers or   *
 *from this link http://timothywayne.cook.googlepages.com/home*
 **

Archetype-triggered events for CDSS

[Sam Heard]

Congratulations - this is great news Tim. Keep up the good work.
Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Tim Cook
 Sent: Tuesday, 14 April 2009 8:56 PM
 To: For openEHR technical discussions
 Subject: Re: Archetype-triggered events for CDSS
 
 On Tue, 2009-04-14 at 12:59 +0200, Pariya Kashfi wrote:
  Hi all,
  In the paper Archetype 101 by Heather and Sam, there's a short
  discussion about CDSS, here comes a quote from it:
  Intelligent generic decision support programs can rely on
  archetype-triggered events and for the first time operate in
  real-time.
 
 
  I wonder what is the exact meaning of Archetype-triggered events.
  IS any research done in this area before or has any implementation
  based on that been used in a CDSS so far?
 
 
 Archetypes allow for embedded First Order Predicate Logic therefore in
 an application they can do some simple internal processing.
 
 The Epidemiological Surveillance Support System (EpiS3)[1] has been
 funded for development (for 3 years, by the INCT-Macc network in
 Brazil) based on the Python implementation of openEHR; aka. OSHIP[2].
 
 Though background work began last year, the funding is expected to be
 released within the next few weeks and development in earnest can
 finally begin. :-)  The OSHIP framework also includes event triggering
 and we will be exploring several options using both of these triggering
 mechanisms in conjunction forward-chaining inference and Bayesian DSS.
 
 [1]  https://launchpad.net/epis3
 [2]  https://launchpad.net/oship/
 
 Regards,
 Tim
 
 --
 Timothy Cook, MSc
 Health Informatics Research  Development Services LinkedIn
 Profile:http://www.linkedin.com/in/timothywaynecook
 Skype ID == timothy.cook
 **
 *You may get my Public GPG key from  popular keyservers or   *
 *from this link http://timothywayne.cook.googlepages.com/home*
 **

Archetype-triggered events for CDSS

[Sam Heard]

Hi Pariya

 

We were really saying that it is possible to write AQL statements (or Xpath)
against archetypes to test if the last bp.systolic  140 mmHg for instance.
This is due to the fact that the archetype makes it quite straightforward to
ask such questions. A number of recent posts have described what is going on
in different developments.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Pariya Kashfi
Sent: Tuesday, 14 April 2009 8:30 PM
To: For openEHR technical discussions
Subject: Archetype-triggered events for CDSS

 

Hi all,

In the paper Archetype 101 by Heather and Sam, there's a short discussion
about CDSS, here comes a quote from it:

Intelligent generic decision support programs can rely on
archetype-triggered events and for the

first time operate in real-time. 

 

I wonder what is the exact meaning of Archetype-triggered events.

IS any research done in this area before or has any implementation based on
that been used in a CDSS so far?

 

 

Regards

Pariya

 

PhD Student 

Department of Computing  Science and Engineering 

Chalmers University of Technology

http://www.cs.chalmers.se/~hajar.kashfi/

 

 

 

 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090421/14ebd58e/attachment.html

Why is the editor not opening ADL files?

[Sam Heard]

Hi William

 

I think this may have been answered elsewhere. The reference model for this
archetype is the openEHR demographic model and it is starting to get some
interest. It is still a research work in progress. These archetypes where
hand built to illustrate ADL working with another model. There are also some
v3 RIM archetypes as well.

 

Cheers, Sam

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of
Williamtfgoossen at cs.com
Sent: 16 March 2009 10:14
To: openehr-technical at openehr.org; openehr-clinical at openehr.org
Subject: Re: Why is the editor not opening ADL files?

 

I got these examples in 2007 from the OpenEHR list. 
This is the one I was working with

Sincerely yours,

dr. William TF Goossen
director 
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
emails: 
Results4Care at cs.com
williamtfgoossen at cs.com 
info at results4care.nl 

phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090316/069b2bcc/attachment.html

AQL queries and one-many relationships

[Sam Heard]

Hi John

I am not sure that this has gone further 
 Hello. I am currently investigating AQL and would like to know how the
 following queries would be answered by a conformant AQL query engine. I
 understand that the structure of AQL query results are not standardized
 yet in the AQL specifications, so if the spec cannot give a definitive
 answer what would Ocean's AQL query engine implementation do?
 
 1.  SELECT
   o/data[at0001]/events[at0031]/data[at0003]/items[at0004]/value AS
 PosturalChangeSystolic,
   o/data[at0001]/events[at1004]/data[at0003]/items[at0004]/value AS
 ParadoxSystolic
 FROM
   EHR
   CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1]
   CONTAINS OBSERVATION o [openEHR-EHR-
 OBSERVATION.blood_pressure.v1]
 WHERE
 
 o/data[at0001]/events[at0031]/data[at0003]/items[at0004]/value/value =
 140 OR
 
 o/data[at0001]/events[at1004]/data[at0003]/items[at0004]/value/value =
 140
 
 This query attempts to find all Systolic readings for Paradox and
 Postural Change blood pressure events where the Systolic reading for
 either is = 140. 

[Sam Heard] These would usually be 0-30 or so but

As there is a one-to-many relationship between a
 blood pressure observation and both Paradox and Postural Change events,
 how should the query be processed? If an observation has three Postural
 Change events where Systolic = 140, and four such Paradox events,
 would the query return twelve rows (using my relational database
 thinking). Or would one row be returned, having two lists (with three
 and four members respectively) of Systolic readings?

[Sam Heard] In the Ocean environment we flatten the response (ie one row).

 
 
 2.  SELECT o
 FROM
   EHR
   CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1]
   CONTAINS OBSERVATION o [openEHR-EHR-
 OBSERVATION.blood_pressure.v1]
 WHERE
 
 o/data[at0001]/events[at0031]/data[at0003]/items[at0004]/value/value =
 140 OR
 
 o/data[at0001]/events[at1004]/data[at0003]/items[at0004]/value/value =
 140
 
 This query is the same as the previous one, except that it returns the
 whole observation. It seems to me that all readings should be returned,
 regardless of their systolic values?

[Sam Heard] Yes, you are selecting all observations that include a paradox
or postural change of  140 (very rare!)

 
 
 3.  SELECT o
 FROM
   EHR
   CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1]
   CONTAINS OBSERVATION o [openEHR-EHR-
 OBSERVATION.blood_pressure.v1]
 WHERE
 
 o/data[at0001]/events[at0031]/data[at0003]/items[at0004]/value/value =
 140 AND
 
 o/data[at0001]/events[at1004]/data[at0003]/items[at0004]/value/value =
 140
 
 This query is the same as the previous one, except that the OR has been
 changed to an AND. It could be argued that only the Paradox and
 Postural Change events with a Systolic reading = 140 should be
 returned, but it could also be argued that all readings should be
 returned, as the whole observation has been selected.

[Sam Heard] Again - the whole observation that meets both criteria should be
returned.
 
 
 The problem I have is how to treat queries which have in the WHERE
 clause a path expression that traverses through a 1:n relationship. In
 trying to think through the semantics of such queries, I come up with
 ambiguities. In a relational query (i.e. SQL) the equivalent path
 expression would have to be expressed as a join between tables in the
 FROM clause, thus removing the ambiguities.
 
 Am I missing something or are my concerns relevant? If so, how does the
 spec/Ocean implementation address them?
[Sam Heard] Hope that helps.

Sam

 
 Thanks,
 
 John Ryan-Brown
 The Australian e-Health Research Centre
 CSIRO ICT Centre
 Brisbane
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

AQL queries and one-many relationships

[Sam Heard]

The contains statement is like a join. It is the association of containment
which is very useful in longitudinal records.
Cheers, Sam

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Greg Caulton
 Sent: 25 February 2009 09:41
 To: openehr-technical at openehr.org
 Subject: Re: AQL queries and one-many relationships
 
 Sorry, I was trying to use an example to explain that in SQL one would
 have a cartesian join if you have
 
 select
t1.*
 from t1, t2
 
 but in AQL the examples I have seen suggest that
 
 select
o
 from c1, o1
 
 would be an implict join
 
 I'll leave the AQL discussions to someone more versed with it :-)
 
 
  --
 
  Message: 4
  Date: Wed, 25 Feb 2009 09:08:28 +1100
  From: John.Ryan-Brown at csiro.au
  Subject: RE: AQL queries and one-many relationships
  To: openehr-technical at openehr.org
  Message-ID:
  ? ? ? ?8C3F2174B3FE2B408CB380513186BEC45752819AE7 at EXNSW-
 MBX03.nexus.csiro.au
 
  Content-Type: text/plain; charset=iso-8859-1
 
  Thanks for your respose Greg.
 
  I'm not really concerned about the details of specific archetypes - I
 just used the ubiquitous blood pressure one because that's the one used
 in a lot of the example documentation.
 
  My question is more about the how AQL should handle querying data
 that conforms to archetypes that contain one or more one-to-many
 relationships.
 
  John
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical