RE: name of language to define OPTs ?

[Heath Frankel]

Hi Georg,
It is an XML serialisation of the Archetype Object Model.

Heath

-Original Message-
From: openEHR-technical  On Behalf 
Of Georg Fette
Sent: Sunday, 13 October 2019 1:41 AM
To: For openEHR technical discussions 
Subject: name of language to define OPTs ?

Hello,
What is the language name in which templates (OPT and OPT2) are defined ?
Greetings
Georg

-- 
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
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: FHIR-like terminology 'binding strengths'?

[Heath Frankel]

Hi Tom,
I agree with Grahame, in over 20 years of implementing real systems, I don’t 
think I recall having seen one value-set that hasn’t been extended at some 
point when locally implemented. Even HL7 defined tables in V2 that were 
supposed to not be extended have been extended.

There is a big difference between best-practice and reality and we don’t want 
to be putting any more barriers to adoption.

To be honest, I am not sure that using required at an archetype level would be 
wise, it may be something that can be used at a template level.

You could argue that preferred covers extensible and I agree that example may 
not be useful in models, but has proven to be useful as a guide for FHIR 
readers.

Therefore, I think we still have Boolean option, either required or 
preferred/extensible/example.

Having said that, using a Boolean doesn’t allow for us to support a valid use 
case in the future and I see some value in aligning with the FHIR options (if 
HL7 allow us to do that) even if we only support a subset.

Regards

Heath

From: openEHR-technical  On Behalf 
Of Grahame Grieve
Sent: Tuesday, 16 April 2019 7:03 AM
To: For openEHR technical discussions 
Subject: Re: FHIR-like terminology 'binding strengths'?

hi Tom

We did not define extensible bindings because we like it. Using it creates many 
issues and it's problematic. We defined it because it's a very real world 
requirement, in spite of it's apparent 'unreliability'.

The use cases arises naturally when
- the approval cycle of changes to the value set is slower than operational 
requirements
- the value set is large, and a community can only get partial agreement in the 
space. This is actually pretty common - typically, clinical code sets may need 
to contain 5000-5 concepts, but most of that is a very lng tail, and 
95%+ of the use comes from 200-400 common codes. There's plenty of clinical 
communities investing time in requiring common agreed codes with fixed 
granularity for the head of the distribution.

Neither of these things are an issue if openEHR is just targeting single 
application functionality. But as soon as the community that maintains the 
value set is wider than the users of a single system, then extensible bindings 
are inevitable.

You can consider it bad... but that doesn't make it go away. Nor does it reduce 
the value of the agreements that do exist.

Grahame


On Tue, Apr 16, 2019 at 1:27 AM Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

Last week, we had a workshop on ADL2 in Germany, to try to sort out a few 
issues on the way to making ADL2 mainstream in openEHR implementations. See 
here for the wiki 
page.

One of the issues discussed was on what basis terminology code constraints 
(value sets, generally) in archetypes (or templates) could be considered 
optional, recommended etc (discussion page 
here).
 Some here will recognise this question as roughly the one that FHIR's 'binding 
strengths' tries to solve. 
I can understand two of the settings:

  *   required: thou shalt use one of these here codes
  *   preferred: we recommend these codes but you can use what you like

I don't know how useful it is to put 'example' value sets in a content model, 
since there might be many possible examples, differing across the world. If 
there is an obvious example that makes sense for the scope / geography of 
application of the archetype, e.g. some SNOMED or LOINC subset, then this seems 
to me to be a case of 'preferred'.

But my main issue is with 'extensible'. In FHIR, this means: you should use one 
of these codes if it applies to your concept, but otherwise you can use 
something else. In my view, in reality, this is the same as 'preferred'. It's 
worth considering what it would mean to mandate codes that are supplied in a 
value-set, but then to say, for other meanings not covered, use something else. 
This means that the value-set is considered not to be complete, i.e. to 
exhaustively cover the concept space. Supplying half-built value-sets seems 
like a very unreliable thing to be doing in shared clinical models. Is the 
value set 90% complete? Or only 10%? The whole idea of specifying partial value 
sets in clinical models just seems bad to me.

If we assume that value sets are always well-designed, and exhaustive, then the 
only real 'binding strengths' are: required | optional.

I have proposed that this be modelled as:

  *   required: Boolean
  *   recommendation: enum ( preferred | example )

If we get rid of the example idea (which I think is just noise) then we just 
need 'required'. If required is false, and there is a value set specified, 
clearly it is 'preferred' or recommended in some sense. If there is no value 
set, it's truly open.

Intereste

Re: openEHR on FHIR and vice versa

[Heath Frankel]

Although I will add, and I think someone has already suggested this, at least 
we only have to do this mapping once for each FHIR resource. So as a 
openEHR/FHIR community we should aim for a set of templates, as Thomas 
indicated, a set of FHIR extensions, and a library of mappings and transforms.
Sounds like LinkEHR has some capacity to do the mappings but from a community 
asset perspective we need a Implementation independent technology for the 
transform. Back in my day of doing HL7 v2 or CDA mappings, this was done using 
XSLT. I think someone mentioned a JSON equivalent? I still think XSLT would be 
a good common denominator although perhaps seen as ancient.

Regards

Heath

From: Heath Frankel
Sent: Wednesday, December 19, 2018 8:23:31 AM
To: For openEHR technical discussions
Subject: Re: openEHR on FHIR and vice versa

Thanks Pablo,
I second that.

Regards

Heath
_
From: Pablo Pazos mailto:pablo.pa...@cabolabs.com>>
Sent: Wednesday, December 19, 2018 3:36 am
Subject: Re: openEHR on FHIR and vice versa
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>


Yes, in fact the closest we can get to automatic transformations is just 
defining the mappings between openEHR classes and the correspondent FHIR 
resources, and feed that to a system that, for a specific openEHR instance, 
provides a mapper user with constrained options of FHIR resources to choose 
from, and vice-versa, given a FHIR resource, provide the options of openEHR 
classes to map to. Then will end up mapping fields of correspondent types. No 
magic here for now :(

But I believe this process can be more intelligent, if we add extra metadata to 
the definitions (like SNOMED CT annotations with concept ids and expressions), 
and we have a lot of instance samples where AI algorithms can run on and detect 
semantic matches. Still, a human needs to do some manual work, but maybe less 
with the extra help of metadata+AI.

Thinking of 100% automatic generic transformations between any instance of two 
different information models is currently just science fiction IMHO :), or for 
a political correct answer: it is an open problem.

On Tue, Dec 18, 2018 at 7:58 AM Ian McNicoll 
mailto:i...@freshehr.com>> wrote:
I agree Pablo and we have to remember that the number of high-quality, truly 
interoperable FHIR profiles is going to be very small for a long time.

@Dileep V S<mailto:dil...@healthelife.in> - we have started to put FHIR 
bindings in CKM archetypes but in practice, the FHIR-openEHR mappings will 
between local FHIR profiles
 and local templates - see  
https://github.com/inidus/openehr-care-connect-adaptor

There are various attempts at automation including the Ripple QEWD Jumper work 
https://www.youtube.com/watch?v=iaGGGgJdWvM but it will still need quite a lot 
of manual input.

Ian

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

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


On Mon, 17 Dec 2018 at 18:26, Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>> wrote:
I also did some mapping work FHIR -> openEHR using Mirth, but this is ad-hoc, 
no automatic mapping yet, for that you need to define a lot of constraints to 
make it work automatically. Maybe some semi-automatic tool come out in the 
future, assisting architects on doing such mappings, either way some kind of 
human intervention will be needed to define mapping criteria when there are  1 
to * mapping possibilities.

On Fri, Dec 14, 2018 at 8:01 AM Jan-Marc Verlinden 
mailto:jan-m...@medrecord.io>> wrote:
We are doing something similar at the moment. but instead of doing this inside 
the archetype we are considering the use of an external mapping tool like Mirth 
Connect or OpenHIM. But we are not there yet.. :-)

Jan-Marc Verlinden
www.medrecord.io<http://www.medrecord.io>
www.medsafe.io<http://www.medsafe.io>
0653785650


Op vr 14 dec. 2018 om 11:49 schreef Diego Boscá 
mailto:yamp...@gmail.com>>:
Hello Georg,

The main result of that paper was supporting FHIR as a reference model to 
define archetypes (you can do that with no limitations on the currently 
available tool). There is no openEHR archetype <-> FHIR profile service yet, 
although I believe that providing a openEHR -> FHIR generical transformation 
could be feasible.
Most of the results of this work are available as import/export functions in 
LinkEHR: Importing StructureDefinitions should work for most things (in fact, I 
have been updatin

Re: openEHR on FHIR and vice versa

[Heath Frankel]

Thanks Pablo,
I second that.

Regards

Heath
_
From: Pablo Pazos mailto:pablo.pa...@cabolabs.com>>
Sent: Wednesday, December 19, 2018 3:36 am
Subject: Re: openEHR on FHIR and vice versa
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>


Yes, in fact the closest we can get to automatic transformations is just 
defining the mappings between openEHR classes and the correspondent FHIR 
resources, and feed that to a system that, for a specific openEHR instance, 
provides a mapper user with constrained options of FHIR resources to choose 
from, and vice-versa, given a FHIR resource, provide the options of openEHR 
classes to map to. Then will end up mapping fields of correspondent types. No 
magic here for now :(

But I believe this process can be more intelligent, if we add extra metadata to 
the definitions (like SNOMED CT annotations with concept ids and expressions), 
and we have a lot of instance samples where AI algorithms can run on and detect 
semantic matches. Still, a human needs to do some manual work, but maybe less 
with the extra help of metadata+AI.

Thinking of 100% automatic generic transformations between any instance of two 
different information models is currently just science fiction IMHO :), or for 
a political correct answer: it is an open problem.

On Tue, Dec 18, 2018 at 7:58 AM Ian McNicoll 
mailto:i...@freshehr.com>> wrote:
I agree Pablo and we have to remember that the number of high-quality, truly 
interoperable FHIR profiles is going to be very small for a long time.

@Dileep V S - we have started to put FHIR 
bindings in CKM archetypes but in practice, the FHIR-openEHR mappings will 
between local FHIR profiles
 and local templates - see  
https://github.com/inidus/openehr-care-connect-adaptor

There are various attempts at automation including the Ripple QEWD Jumper work 
https://www.youtube.com/watch?v=iaGGGgJdWvM but it will still need quite a lot 
of manual input.

Ian

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

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


On Mon, 17 Dec 2018 at 18:26, Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>> wrote:
I also did some mapping work FHIR -> openEHR using Mirth, but this is ad-hoc, 
no automatic mapping yet, for that you need to define a lot of constraints to 
make it work automatically. Maybe some semi-automatic tool come out in the 
future, assisting architects on doing such mappings, either way some kind of 
human intervention will be needed to define mapping criteria when there are  1 
to * mapping possibilities.

On Fri, Dec 14, 2018 at 8:01 AM Jan-Marc Verlinden 
mailto:jan-m...@medrecord.io>> wrote:
We are doing something similar at the moment. but instead of doing this inside 
the archetype we are considering the use of an external mapping tool like Mirth 
Connect or OpenHIM. But we are not there yet.. :-)

Jan-Marc Verlinden
www.medrecord.io
www.medsafe.io
0653785650


Op vr 14 dec. 2018 om 11:49 schreef Diego Boscá 
mailto:yamp...@gmail.com>>:
Hello Georg,

The main result of that paper was supporting FHIR as a reference model to 
define archetypes (you can do that with no limitations on the currently 
available tool). There is no openEHR archetype <-> FHIR profile service yet, 
although I believe that providing a openEHR -> FHIR generical transformation 
could be feasible.
Most of the results of this work are available as import/export functions in 
LinkEHR: Importing StructureDefinitions should work for most things (in fact, I 
have been updating this part recently and will have better support for STU3 in 
next LinkEHR version we publish). The export feature is in the original DSTU 
format though, I assume we should go further and generate StructureDefinitions 
as in STU3. For the transformation of data instances, as I said we use 
archetypes as way to express FHIR profiles and resources, so transforming 
between them is no more difficult than transforming between openEHR, CDA, 
ISO13606, ODM, etc. which you can do with the LinkEHR studio (FYI, the LinkEHR 
Studio version available on the website allows you to test this 
mapping/transformation part, the only thing you won't be able to do is to 
export the output XQuery transformation)

Regards

El vie., 14 dic. 2018 a las 11:19, Georg Fette 
(mailto:georg.fe...@uni-wuerzburg.de>>) escribió:
Hello,
I have just read the paper "Combining Archetypes with Fast Health
Interoperability Resources in Future-proof Health Information Systems",
in wh

Re: Better definition of 'system_id' attribute in openEHR sytems

[Heath Frankel]

Hi Thomas,
This is an excellent description and is inline with our implementation.

Regards

Heath

From: 3003270n behalf of
Sent: Monday, November 26, 2018 11:43 pm
To: Openehr-Technical
Subject: Better definition of 'system_id' attribute in openEHR sytems


Following SPECPR-99 andthis 
email 
string
 from 2014, the imminent RM 1.0.4 release will include 
SPECRM-80, which improves the 
documentation about system_id, which is recorded in the EHR and also in 
AUDIT_DETAILS, i.e. on each committed version.

In response to this, I have added the following documentation to the 
Architecture Overview, and will also add further text and hot links to the 
specific locations in the EHR and Common parts of the RM. It would be useful to 
know if this agrees with the understanding of openEHR system implementers and 
users.



6.1. The EHR System

The notion of a logical EHR system is central to the openEHR architecture. In 
openEHR, a system is understood as a distinct logical repository corresponding 
to an organisational entity that islegally responsible for the management and 
governance of the healthcare data contained within. This may be a regional 
health service that serves multiple provider enterprises or a single provider 
enterprise such as a larger hospital. The 'system' is therefore in general 
distinct from specific applications and also from provider organisations, even 
if in some cases it happens to be owned by a single provider. It is also 
distinct from any underlying virtualisation infrastructure or cloud computing 
facility, which may house multiple logical EHR systems in a multi-tenant 
fashion. This is clear by comparing the legal responsibilities of the 
infrastructure provider, which are forgeneric IT service management to a 
procurer, which may be a healthcare data management entity. It is the latter 
that undertakes legal responsibility for the content, on behalf of one or more 
healthcare provider organisations.

The technical criterion for identifying an EHR system is that it is the entity 
that assigns version identifiers within a repository.

6.1.1. System Identity

Within the openEHR architecture, a system_id attribute is recorded both within 
each patient EHR (EHR class), and also within the audit created with each 
commit of data to an EHR (AUDIT_DETAILS class). This identifier identifies the 
logical EHR system as described above, and may be of any form. Common forms 
include the reverse domain name and plain and structured string identifiers. 
The system identifier isnot assumed to be directly processable, but may instead 
be used as a key, for example in a service maintaining location information.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: AOM 1.4 - Archetype.uid a UUID or OID?

[Heath Frankel]

Hi Thomas,
Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is used for 
OIDs is incorrect. HIER_OBJECT_ID is a complex type with a value attribute of 
type UID, which may be either UUID, ISO_OID or INTERNET_ID.

The bigger issue is the HIER_OBJECT_ID is incompatible with UUID from a XML 
schema perspective as UUID is a simple type with a restricted string value 
while HIER_OBJECT_ID is a complex type with a child element value. The V1.4 AOM 
XML schema uses this HIER_OBJECT_ID type (as per the AOM specification) and 
since the OPT schema inherits this model, it also uses this type and all OPTs 
generated by CKM (and the template designer) populate the uid element with the 
template GUID specified in the OET file.

I suggest that the ADL 2 specification is that one that needs to change or 
there needs to be a specified mapping between the two.

Regards

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, 15 June 2017 5:40 AM
To: Openehr-Technical 
Subject: AOM 1.4 - Archetype.uid a UUID or OID?




Bert picked up an anomaly in this 
PR that I think should 
probably be fixed. ARCHETYPE.uid is of type UUID in the AOM2 spec, but of type 
HIER_OBJECT_ID in the AOM1.4 spec (the latter type is the openEHR type for 
OIDs). However it appears that all ADL1.4 archetypes that have a uid have it as 
a Guid (i.e. UUID), and I assume the various tools do as well. We avoid Oids 
like the plague in openEHR, and I am not aware of them being used anywhere.

If we can verify that everything assumes a UUID for this field, then the spec 
is wrong, and we should update it from 1.4.2 to 1.4.3, i.e. treat this as an 
error correction.

Could tool makers check this issue and report here?

thanks

- thomas

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

Re: Could the specs group consider making uid mandatory?

[Heath Frankel]

I think it should be a strong recommendation rather than mandatory considering 
it is currently optional and the need for backward compatibility.
I also think it maybe difficult to apply consistently in some cases such as 
feeder data. There are cases in CDA profiles where there are mandatory IDs and 
you have to populate it with something but then need to some how retain this 
same ID over revisions etc.
I also think a uri should be an allowed type of UID to support ids that are not 
guids and possibly associated with real world ids such as lab result ids, etc.

Regards

Heath




On Mon, Dec 19, 2016 at 8:35 AM +1030, "Thomas Beale" 
mailto:thomas.be...@openehr.org>> wrote:



I also think that would be a good idea, since ENTRY = clinical
statement. We could make it an openEHR rule.

- thomas


On 14/12/2016 00:24, Ian McNicoll wrote:
> There may be some advantages in routine application of uid at ENTRY level.
>
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>


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

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

RE: Specs about ACTIVITY.timing still unclear

[Heath Frankel]

We have more recently used iCAL for Instruction timing not associated with 
Medication orders such as service requests. It has served us well so far. 
Although FHIR has its own Appointment resource, they actually suggest the use 
of iCal instead of using this resource.

I am not sure if iCal could be used for Medication, theoretically it may be 
possible but we would need someone that knows iCal better than I and a 
clinician to work through the use cases.

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Wednesday, 13 July 2016 5:59 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Specs about ACTIVITY.timing still unclear




On 26/06/2016 22:23, pablo pazos wrote:
Thanks for your message Ian,

IMO avoiding the implementation of ACTIVITY.timing raises the question of why 
that was introduced in the model and if we should keep it or not.

it was included on the assumption that timing would be represented as a formal 
expression, like HL7 GTS, which uses a ISO 8601-derived expression. I think the 
attribute should stay there because it allows this kind of approach, which is 
more computable. Whether it is always used is another question - I am concerned 
that there may be too much ad hoc modelling going on in archetype-land, without 
paying enough attention to the RM facilities in some areas.



On the other hand, I think timing there can be a powerful tool for advanced 
systems that can use that info to manage / automate flows / processes.


The problem with timing is that it is difficult to specify in a generic way, 
and I have seen at least 3 kinds of proposals:

1. Computable expressions
2. Terminology based
3. Structure based


1. Computable expressions

+ idea: try to define a code that can be processed by software.
+ pro: everyone loves codes, systematized approach
+ con: expressions are too complex to be defined just by a code, makes this 
solution almost unrealistic.

only some expressions are too complex; most are not. It's always a 90/10 
situation. I think the mistake on the part of some is that because there is a 
10% set of cases that can't easily be represented as expressions, they want to 
ditch that approach and use something else entirely, when in fact expressions 
would work most of the time.




2. Terminology based

+ idea: just define all the possible timing schemes and their definitions e.g. 
QID, Q4H, AC, PC, ...
+ pro: easy to use, easier to define and maintain than approach 1.
+ con: ?

the con is that you have to have a terminology concept for every possible 
permutation of expressions - that's not realistic. Unless you rely on 
post-coordination, but then you are really just using terminology as a weak 
expression language.



3. Structure based

+ idea: define a structure (maybe a hierarchy in an UML model) to represent 
different timing expressions (like the HL7 time expressions datatypes or what 
Ian mentioned of creating a CLUSTER archetype)
+ pro: easy to specify in an OO model, extendable, easy to implement (the model 
can include state + behavior)
+ con: ?

this is the equivalent of 1. If you can represent something as a formal 
structure, you can represent it as an expression, these are two things that lie 
on either side of the thing called a parser ;-)

Also, the structural representation of a very compact expression string may be 
quite large.




I would like we consider to make a proposal on how to use timing on the openEHR 
specs, oriented to implementation, and not focused only on medication (current 
specs examples are just for medication).

I'm not sure if we need to do anything special - if someone wants to use FHIR 
timing, we just need an 
expression form of that, and since ACTIVITY.timing is a DV_PARSEABLE, its 
syntax can be set to 'FHIR::timing' or similar.

- thomas



1. We can extend our timing specification to be compatible with the HL7 / FHIR 
one (add/modify our datatypes). I think with this we don't need to make custom 
timing specs on archetypes.
2. Add to our terminology spec the most commonly used terms for timing, so we 
can use them as part of our timing specification.
3. Add more examples oriented to long term treatment, procedures, tests, etc. 
alongside with medication therapy in the specs, or maybe in a "timing addendum".

OR

Define to remove timing completely from the openEHR model and rely on 
archetyped timing on ACTIVITY.description.


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6201 / Virus Database: 4627/12599 - Release Date: 07/11/16
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: initial states for instructions / when do we need actions?

[Heath Frankel]

Hi Pablo,
Some comments below.

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Tuesday, 12 July 2016 12:29 PM
To: openeh technical ; openehr clinical 
; s...@lists.openehr.org
Subject: ISM: initial states for instructions / when do we need actions?

Hi all,

This message is related to my previous message "ACTIVITY.description vs 
ACTION.description archetypes‏" (didn't got any answers :( but this is focused 
on when we need actions to change a instruction state, and what's the initial 
state.

Considering the specs:
http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_the_standard_instruction_state_machine_ism

I think when an instruction is firstly recorded, it should have a state. But 
I'm not 100% if that state should be INITIAL, or can also be PLANNED, SCHEDULED 
or ACTIVE, since at least for SCHEDULED and ACTIVE I think we need an ACTION to 
be recorded to trigger the transition, but it is not clear that we need that to 
trigger the transition "initiate (INITIAL -> PLANNED)".

[HKF: ] I personally consider the Initial state as your standard state diagram 
starting point rather than a usable state. The AE has allowed the initial state 
to be used, which I think is incorrect and we translate this to a subsequent 
state for real use.

1- Is INITIAL the state associated with an instruction when no action is 
recorded?

[HKF: ] This is how I consider this. In fact I usually explain to my developers 
that an instruction is not initiated unless there is an action to start the 
instructions workflow. Without an action, it is just a definition of an 
instruction that is waiting to have its workflow started.

2- If what it's recorded is a medication prescription, I guess the initial 
state should be PLANNED, do we need to record an action alongside with the 
instruction to make the "initiate (INITIAL -> PLANNED)" transition? OR, we can 
just set the initial state to PLANNED, even though no actions are recorded for 
the instruction/activity?

[HKF: ] As indicated, I would have an ACTION with a PLANNED state to make this 
clear. You may choose to go straight to Active.

3- On the case of recording a treatment that should be scheduled, do we also 
need an action to trigger the "schedule (INITIAL -> SCHEDULED)" transition? (I 
guess yes if the instruction is created at one time, and the schedule comes 
later).

[HKF: ] As above.

3.1- If yes, what happens on the case the instruction includes scheduling? 
Should we include an action to trigger the transition or can we set the state 
to SCHEDULED directly?

[HKF: ] Sorry, I don’t understand this one.

At least for me this is not 100% on the specs. If this happens to others, we 
might need to improve the specs and add more examples to make this topic clear 
for newcomers.

Thanks!


--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Shouldn't INSTRUCTION_DETAILS.wf_details be archetypable?

[Heath Frankel]

Hi Pablo,
Since wf_details is ITEM_STRUCTURE, then yes it can be archetyped. Just because 
the AE doesn't support it does not change this fact. As is this case in many 
software projects, functionality in the AE was built on as needed basis so I 
would suggest that no one has needed it to date. Since the AE was almost 100% 
contributed by Ocean Informatics, the priorities around "as needed" was 
evaluated by Ocean. However, the AE is open source so others can add their own 
capabilities if they desire.

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Tuesday, 12 July 2016 2:36 PM
To: openeh technical ; openehr clinical 
; s...@lists.openehr.org
Subject: Shouldn't INSTRUCTION_DETAILS.wf_details be archetypable?

Looking at the model, INSTRUCTION_DETAILS.wf_details is an ITEM_STRUCTURE, and 
that lead me to think that should be archetypable.

Playing around with the archetype editor, it doesn't allow to archetype 
anything inside INSTRUCTION.instruction_details.

Is this a problem of the AE or that structure is not meant to be archetyped?

If it is not meant to be archetyped, wouldn't that be an issue for querying?

Thanks!

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Composition commit and change types

[Heath Frankel]

Hi Pablo,
I did include my scenarios re problem list at the bottom of the email. Having 
said that there had been some movement around what compositions are persistent 
due to no context issues so problem list may no longer be a persistent 
composition.
There are similar scenarios for other persistent compositions also, it all 
comes down to context of use.

As I said, I don't like advising how others implement their systems so if you 
think your users will benefit from this rule then go ahead, I was more 
concerned about Ian's response sounding definitive than your query. This has 
risen a interesting topic for the API SEC to address.

Regards

Heath




On Sun, Apr 3, 2016 at 10:23 PM -0700, "pablo pazos" 
mailto:pazospa...@hotmail.com>> wrote:

Hi Heath,

> There are way too many use cases where our service is used and many will 
> break this scenario like merges, distributed EHRs and cross organisational 
> shared records.

It would be helpful if you share which scenarios break the rule I stated on the 
previous email to improve it.


IMHO I don't think anybody will take this little convo as a de facto standard, 
also I'm not trying to set that, never stated that. I just want to make the 
life of my users simpler by establishing an initial set of rules they can use 
until they find requirements that might need a more complex rule set, to have 
many cases that should be supported. I prefer that to start, instead of leaving 
the definition of the rules 100% to the clients of my API, considering that 
most of them won't have any experience with openEHR and how an openEHR backend 
should work. Of course this might work for my tools and my target customers, 
and I know this won't fit everybody, but this rule might help others to adapt 
it to their specific needs. And I agree if this has to be defined for an API 
behavior, the API SEC should be the place to define it.
--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com


From: heath.fran...@oceaninformatics.com
To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org
CC: openehr-technical@lists.openehr.org
Subject: Re: Composition commit and change types
Date: Sun, 3 Apr 2016 23:36:25 +

Hi Ian and Pablo,
Although I don't like commenting on how others implement their systems I would 
hate for this discussion to become the defacto standard on how the API works in 
the context of persistent compositions.
Although I understand Ian's position on best clinical practice of a single 
medication list represented as a persistent composition in a person's EHR, 
there is nothing stated about this in the specifications.
I would be interested in other vendors implementations in this area, but as a 
service implementation I do not like makinging these application oriented 
decisions unless they are in the specification. There are way too many use 
cases where our service is used and many will break this scenario like merges, 
distributed EHRs and cross organisational shared records.
I think it is the application that needs to apply these business rules.
I think this needs to be addressed by the API SEC before recommendations that 
appear normative are made on the lists.
Personally we have had big problems with persistent compositions due to lack of 
context, although we are working on fixing these, I still feel that perhaps we 
are not ready to have the category attribute constrained in the archetypes that 
we currently state are persistent for these same reasons. I have seen cases 
where there is a desire for different problem lists from different clinical 
perspectives, in particular a consumers view vs a GP vs a specialist.

Regards

Heath




On Sun, Apr 3, 2016 at 11:34 AM -0700, "Ian McNicoll" 
mailto:i...@freshehr.com>> wrote:

That looks correct to me :)

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 3 April 2016 at 19:20, pablo pazos  wrote:
> @Bert, no worries :)
>
> @Ian, for now, I'll add a rule like this:
>
> If committed compo is persistent
>   If there is no versioned_compo for the root archetype of the committed
> compo // this check is new
> If change_type == creation // only allows to create one persistent
> compo, all other commits should be modifications
>   create versioned_compo with version v1
>   return 200 OK
> Else
>   return 400 Bad Request
>   Else
> If change_type in [amendment, modification]
>   create new version in existing versioned_compo // this will create v2,
> v3, ...
>   return 200 OK
> Else // not considering delete for now, this do not allows to create
> another instace v1 for the same persistent compo archetype
>   return

Re: Composition commit and change types

[Heath Frankel]

Hi Ian and Pablo,
Although I don't like commenting on how others implement their systems I would 
hate for this discussion to become the defacto standard on how the API works in 
the context of persistent compositions.
Although I understand Ian's position on best clinical practice of a single 
medication list represented as a persistent composition in a person's EHR, 
there is nothing stated about this in the specifications.
I would be interested in other vendors implementations in this area, but as a 
service implementation I do not like makinging these application oriented 
decisions unless they are in the specification. There are way too many use 
cases where our service is used and many will break this scenario like merges, 
distributed EHRs and cross organisational shared records.
I think it is the application that needs to apply these business rules.
I think this needs to be addressed by the API SEC before recommendations that 
appear normative are made on the lists.
Personally we have had big problems with persistent compositions due to lack of 
context, although we are working on fixing these, I still feel that perhaps we 
are not ready to have the category attribute constrained in the archetypes that 
we currently state are persistent for these same reasons. I have seen cases 
where there is a desire for different problem lists from different clinical 
perspectives, in particular a consumers view vs a GP vs a specialist.

Regards

Heath




On Sun, Apr 3, 2016 at 11:34 AM -0700, "Ian McNicoll" 
mailto:i...@freshehr.com>> wrote:

That looks correct to me :)

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 3 April 2016 at 19:20, pablo pazos  wrote:
> @Bert, no worries :)
>
> @Ian, for now, I'll add a rule like this:
>
> If committed compo is persistent
>   If there is no versioned_compo for the root archetype of the committed
> compo // this check is new
> If change_type == creation // only allows to create one persistent
> compo, all other commits should be modifications
>   create versioned_compo with version v1
>   return 200 OK
> Else
>   return 400 Bad Request
>   Else
> If change_type in [amendment, modification]
>   create new version in existing versioned_compo // this will create v2,
> v3, ...
>   return 200 OK
> Else // not considering delete for now, this do not allows to create
> another instace v1 for the same persistent compo archetype
>   return 400 Bad Request
>
>
> For event compos, it just follows the common versioning flow, allowing to
> create any number of v1 instances with change_type creation, and version
> them using amendment or modification.
>
> Does this makes sense? If yes, maybe this can help other implementations :)
>
> --
> Kind regards,
> Eng. Pablo Pazos Gutiérrez
> http://cabolabs.com
>
>> From: i...@freshehr.com
>> Date: Sun, 3 Apr 2016 11:06:53 +0100
>> Subject: Re: Composition commit and change types
>> To: pazospa...@hotmail.com
>> CC: openehr-technical@lists.openehr.org
>
>>
>> " I would focus on intra hospital longitudinal lists since it is very
>> difficult to reach agreement in the enterprise."
>>
>> I agree. These decisions are partly technical but largely down to the
>> level of commitment/ consensus you can get in your clinical community
>> to jointly curate these lists over time. The value of longitudinal
>> persistence only accrues if everyone has commitment to the on-going
>> curation process and is prepared to work within a common governance
>> framework, rights and responsibilities.
>>
>> http://www.bcs.org/content/conWebDoc/17923
>>
>> 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 3 April 2016 at 09:07, pazospa...@hotmail.com 
>> wrote:
>> > Good info and the criteria makes sense.
>> >
>> >
>> > I would use episodic for things like hospitalization and treatments that
>> > are
>> > not a knee time thing (event), maybe with help of folders. Also I would
>> > focus on intra hospital longitudinal lists since it is very difficult to
>> > reach agreement in the enterprise. And when that time comes, I would
>> > just
>> > implement a new set of rules for the enterprise :)
>> >
>> >
>> > Thanks!
>> >
>> >
>> > Sent from my LG Mobile
>> >
>> > -- Original message--
>> >
>> > From: Ian McNicoll
>> >
>> > Date: Sat, Apr 2, 2016 15:50
>> >
>> > To: For openEHR technical discussions;
>> >
>> > Subject:Re: Composition commit and change types
>> >
>> > Hi P

RE: Adressing of i.e. discharge summaries

[Heath Frankel]

Hi Bjorn,
Yes we have used these archetypes for representing the service request at both 
the instruction and composition level. Our instruction starts in a care plan so 
we have to represent the referred to provide in the instruction participations. 
Then when we send the referral we copy it to the receiving provider 
participation in the eReferral composition.

Since a discharge summary is a kind of transfer of care then I would expect it 
to have a similar participation when it is being directed to a primary care 
provider although this doesn't need to be populated when it is being uploaded 
to a national repository for example.

Regards

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bjørn Næss
Sent: Wednesday, 16 March 2016 4:42 PM
To: openehr-technical@lists.openehr.org
Subject: Adressing of i.e. discharge summaries

There is a lot of compositions that is created for the purpose of sending the 
content to another healthcare provider. Discharge summaries is one example.
For instruction health care service request there is some elements and slots 
added to the protocol part. Here you can add both the requestor and the 
identifier.

In the Nehta CKM there is a composition archetype for referral. This archetype 
has some structure under context to add participation and identification of the 
requestor. I think this pattern would be the right way to do this.

Anyone with experiences or suggestions on how to do this?



Best regards
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6189 / Virus Database: 4540/11798 - Release Date: 03/11/16
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: rm_type_name for the DV_DURATIONs primitive object in XML

[Heath Frankel]

Hi Sebastian,
Does this mean that CKM no longer uses the TD OPT Web Service?

I think your suggestion of String is correct as per the specifications, 
DURATION, DV_DURATION and C_DURATION are clearly wrong.

However, I think we need to be considering the XML Schema approach of a 
restricted string since the RM does have an invariant of 
is_valid_iso8601duration. I think this needs to be more specifically implied 
using the assumed ISO8601_DURATION class which would allow this to be used in 
the OPT but I think this needs to be considered by the SEC before we adopt this 
approach.

For now I suggest all tools are updated to use String to align with the spec.

Regards

Heath

_
From: Diego Boscá mailto:yamp...@gmail.com>>
Sent: Wednesday, March 16, 2016 2:32 AM
Subject: Re: rm_type_name for the DV_DURATIONs primitive object in XML
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>


To make things worse, in the XML Schema DV_DURATION contains an
Iso8601Duration, which in the end is an string with a regex

2016-03-15 16:43 GMT+01:00 Sebastian Garde
mailto:sebastian.ga...@oceaninformatics.com>>:
> OK, that would have been my pick as well.
>
> Only that:
> - The Java Ref Impl exports it as DV_DURATION (It seems we all agree that 
> this is wrong)
> - Template Designer (2.8) exports this as "DURATION" (in the generated OPT).
> - The online Template Editor seems to export it either as C_DURATION or 
> DURATION in the 1.4 OPT export (depending on what is constrained?!)
>
> So it seems that C_DURATION is another candidate.
>
> I could however not get any of the tools to just use "String"...
>
> Sebastian
>
>
> -Original Message-
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
> On Behalf Of Diego Boscá
> Sent: Dienstag, 15. März 2016 14:04
> To: For openEHR technical discussions 
> mailto:openehr-technical@lists.openehr.org>>
> Subject: Re: rm_type_name for the DV_DURATIONs primitive object in XML
>
> Agree with bostjan, In fact DV_DURATION type is being assigned to both the 
> C_Complex_object and the C_Primitive_object rm_type_name, which is surely 
> wrong.
>
> 2016-03-15 13:42 GMT+01:00 Boštjan Lah 
> mailto:bostjan@marand.si>>:
>> Hi,
>>
>> according to the specs it's String:
>> http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.h
>> tml#_dv_duration_class
>> That's what template designer does.
>>
>> Best regards,
>> Bostjan
>>
>> On 15 Mar 2016, at 13:35, Sebastian Garde
>> mailto:sebastian.ga...@oceaninformatics.com>>
>>  wrote:
>>
>> Dear all,
>>
>> There are a differences in how the Template Designer and how CKM
>> construct the XML for a DV_Duration:
>>
>> Take this snippet (from
>> http://openehr.org/ckm/#showArchetype_1013.1.123_XML
>> )
>>
>> 
>> DV_DURATION
>> 
>> true
>> true
>> false
>> false
>> 1
>> 1
>> 
>> 
>> 
>> value
>> 
>> true
>> true
>> false
>> false
>> 1
>> 1
>> 
>> 
>> DV_DURATION
>> 
>> true
>> true
>> false
>> false
>> 1
>> 1
>> 
>> 
>> 
>> PMWD
>> 
>> true
>> true
>> 
>> 
>> 
>> 
>> 
>>
>> What is the correct rm_type_name for C_PRIMITIVE_OBJECT here (in old
>> red above)?
>>
>> Is it “DV_DURATION” as the Java Ref Impl uses or is it simply “DURATION”
>> (both for reason I don’t really understand) or should it maybe be
>> “String” or “ISO8901_DURATION” as
>> http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_143
>> 3773264460_352968_7042
>> and/or
>> http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_142
>> 2968609347_115062_25681
>> describe.
>>
>> Frankly I am confused, but I hope that someone can enlighten me here?
>>
>> Cheers
>> Sebastian
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
>> ehr.org
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
>> ehr.org
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

RE: Usage of Compositoin.Category

[Heath Frankel]

Hi Bjorn,
How did you come up with the concept id of 434? We need to be careful about 
assigning our own concept ids, we really need openEHR to assign these, I 
suggest through the SEC process initiated by a Jira card.

At present we have two terminology files, as you know we have agreed to use the 
java implementation's terminology xml file as the interim standard 
representation but there are already concept ids allocated in the Archetype 
Editor terminology file which existed before the terminology specification and 
the java implementation. In this case it looks like 434 is safe to use as it is 
not assigned to an openEHR concept in the Archetype Editor, but 435 is 
allocated to an openEHR concept in the setting group, which appears to be 
missing from the terminology specification and the java implementation xml.

Let's start using the SEC process for managing openehr terminology concepts.

Regards

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bjørn Næss
Sent: Friday, 4 March 2016 6:46 PM
To: For openEHR technical discussions 
Cc: Team Selecta 
Subject: SV: Usage of Compositoin.Category

I just added a «composition category» on my fork of the terminology project.

https://github.com/bjornna/terminology/commit/600dec3058cd85f9db3e5859d6bffa7f01a45edf



   
   
+ 


Any comments?

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Bjørn Næss
Sendt: onsdag 17. februar 2016 22.00
Til: 
openehr-technical@lists.openehr.org
Emne: Usage of Compositoin.Category

We are discussing the use of Composition.Category which is a DV_CODED_TEXT.
There is a terminology:


   
   


Is it required to use only these categories or could an application set any 
DV_CODED_TEXT?

I think it would be ok to allow any category in this.

To be concrete:
The use-case is discharge summaries. These are Compositions which only 
("mostly") contains links to existing entries. We will be using links but since 
the Composition should be transferred to another health provider it must be 
serialized and validated against an template. Technically this Compostions 
contains a lot of entries which is "link to self".

The idea we are considering is to introduce a category for these Compositions. 
The content will not be part of AQL results for normal use-cases. But IF you 
ask explicit for these categories you will be able to query for discharge 
summaries which contains body weight above 120 kg.
 If we only add the references as links it will not be possible to add them 
into forms and neither use a Template to validate the content. This is the 
reason we are "thinking out of the box".

Any comments on this?


Best regards
Bjørn Næss
Product Owner - Arena EHR
DIPS ASA

Mobil +47 93 43 29 10


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6189 / Virus Database: 4537/11743 - Release Date: 03/03/16
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Template Designer alternatives

[Heath Frankel]

Hi Pablo,
Since templates are intended to assign terminology bindings for specific 
implementation, the Template Design skips the step to need to specify a coded 
text type and allows you to specify a terminology binding using the Value set 
(terminology) property as shown below.

[cid:image001.png@01D172D2.9C4018C0]

[cid:image002.png@01D172D3.08CCCB00]

The above tab uses the Ocean terminology service (DEMO), you can select 
predefined value set or select a full terminology. The Generic Value Set tab 
allows your own value set references

[cid:image003.png@01D172D3.08CCCB00]


Alternatively, you can specify an inline value set using the property above as 
shown below. Select the Terminology checkbox, enter the code and value and 
finally the terminology drop down list (this needs to be last to get the + 
button to enable).

[cid:image004.png@01D172D4.97251C80]

Both of these methods result in the OPT outputting a CODE_TEXT constraint.

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: Sunday, 28 February 2016 5:25 PM
To: openeh technical ; openehr 
implementers 
Subject: Template Designer alternatives

HI all,

I tried the latest release of the TD and keeps having some constraints on 
modelling, like the impossibility of specifying that a DV_TEXT will be used as 
DV_CODED_TEXT on the data type option, or removing (0..0) slots that will not 
be used on the final OPT.

I'm wondering if are there any template designer alternatives to create 
operational templates, that allows to set DV_TEXTs as DV_CODED_TEXT only or 
setting the 0..0 occurrence to SLOT nodes.

Thanks!


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

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6189 / Virus Database: 4533/11681 - Release Date: 02/22/16
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Heath Frankel]

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

Regards

Heath




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

Thanks Heath,

That makes sense. Does OceanEHR validate the constraint?

Ian

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

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

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

Regards

Heath

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



Hi Koray,

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

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

Ian

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

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

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

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

An example ADL:

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

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

Cheers,

-koray


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




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

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

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

[Heath Frankel]

Hi Koray,
This is a constraint on the value that origin function returns rather than 
indicating it is a settable attribute. This was how Sam defined the events on 
an apgar score, 1 min, 5 min, etc.

Regards

Heath

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


Hi Koray,

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

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

Ian

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

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

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

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

An example ADL:

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

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

Cheers,

-koray


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



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

RE: Missing support for ISM_TRANSITION/transition in Archetype Editor and Template Designer

[Heath Frankel]

Hi Ian,
Although it may be worth doing this in the new web tools, there are existing 
tools being used by many more existing users that need to support this 
functionality, at least in a lossless manner.

Each of the tooling providers need to have the opportunity to be involved in 
the process and agree on the implementation approach to ensure compatibility 
between tools. As you say, there are downstream tooling dependencies and there 
may be a mixture of tooling providers that provide the end to end tool chain. 
This doesn’t even take into account the impacts on software developers who have 
existing operational products.

The entire process actually needs to start with getting agreement on what the 
constraints look like in ADL, etc. I must say, the current ADL representation 
of ISM_TRANSITION constraints is not pleasant and this sounds like it may be 
taking this even further. Again, the impacts on how operational systems will 
consume this need to be considered.

I would recommend that the openEHR Software Program takes the role of 
coordinating this significant tooling enhancement since it has such widespread 
implications.

Regards

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Monday, 30 November 2015 3:22 AM
To: For openEHR technical discussions 
Subject: Re: Missing support for ISM_TRANSITION/transition in Archetype Editor 
and Template Designer

I wonder if this might be work that might be worth doing in the new open-source 
Web tools, developed by Marand at https://github.com/openEHR/adl-designer?

Whether it makes sense to update the new tools or whether we opt to update AE 
and TD, as I said in the other thread about Demographics archetype support, it 
is vital that we work as a community on this, and not simply rely on the 
goodwill of one or two vendors.

The whole area of workflow support and aspects like Pathways and transitions is 
right at the cutting edge of openEHR implementation so it should be no surprise 
that the tooling has gaps and bugs in this area. Those of us who rely on these 
tools professionally/commercially, I believe, must be prepared to support their 
development in-kind. In due course, I do hope that the Foundation can underpin 
this vital work with some seed funding but we are not there yet, and must rely 
on broad community input.

Ian


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

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

On 27 November 2015 at 23:10, Peter Gummer 
mailto:peter.gum...@oceaninformatics.com>> 
wrote:
On 28 Nov 2015, at 00:36, Ivar Yrke mailto:i...@dips.no>> wrote:
>
> Are there any plans to include transition support in these tools? Is there 
> anything we are overlooking in our approach?


Hi Ivar,

Until two years ago the Archetype Editor used to have a Transitions option from 
the Pathway Specification. It had never worked in any previous version of the 
Archetype Editor, however; and up until that time no one had ever found that 
the transition constraints should be limited more than the standard openEHR 
state diagram.

Pablo Pazos raised a problem report that alerted us to the fact that it wasn’t 
working:
https://openehr.atlassian.net/browse/AEPR-6

Pablo’s discussion about it on CKM is here (log in, click on the Discussion 
button, and expand the replies):
http://ckm.openehr.org/ckm/#showArchetype_1013.1.123

The partial implementation that was in place in the Archetype Editor until then 
seemed back-to-front with respect to the reference model: the RM specifies that 
ISM_TRANSITION.transition is the transition that occurred to arrive in the 
current state, whereas the user interface was constraining which states could 
be reached from the current state. To avoid confusion, we removed the 
non-functional implementation after Pablo reported it.

If people actually need to constrain transitions, then there is some work to do 
in the Archetype Editor. First of all, we would have to decide what the ADL and 
XML should look like. Pablo suggested that the ADL would be just a constraint 
of a DV_CODED_TEXT attribute (ISM_TRANSITION.transition), like the constraints 
on ISM_TRANSITION.current_state or ISM_TRANSITION.careflow_step.

Apart from the work in the Archetype Editor, it would affect downstream tools 
which would start to encounter constraints on ISM_TRANSITION.transition for the 
first time; and, as always when implementing something for the first time in 
archetypes, this entails a risk that those downstream tools might break. The 
Template Designer, OPT generation and CKM would all be likely to need fixes 

Re: Binding to multiple terminologies / code systems

[Heath Frankel]

It should also be noted that normally constraints on which terminologies can be 
used in a particular implementation is done in a template. This can be done on 
the existing DV_TEXT definition or on a DV_CODED_TEXT constraint. This can be 
expressed in the template designer, again not the best UI but you get there... 
Not sure that archetype constraint bindings help in this step.

Regards

Heath

On 30 Oct 2015, at 5:37 am, Ian McNicoll 
mailto:i...@freshehr.com>> wrote:

Hi Dave,

As Thomas suggests, it does depend on whether you expect to be binding to a 
single term from the terminology

e.g.

DNACPR decision in http://clinicalmodels.org.uk/ckm/#showArchetype_1051.32.185

in which case Dmitry's advice is correct and the Archetype Editor allows you to 
add bindings to
any/all of the terms via the terminology, then term-binding tab. Not the nicest 
UI but you get there!!

If the target needs to be selected from a list of possible options then 
Thomas's advice is appropriate. One issue is that we do not have good industry 
standard ways of defining these external refset bindings, though  it looks as 
if FHIR might get some traction.

Examples in this archetype 
http://clinicalmodels.org.uk/ckm/#showArchetype_1051.32.4

Ian


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

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

On 29 October 2015 at 18:24, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

The answer isn't completely simple. Some background 
here.
 If there are bindings defined for snomed_ct, read2 and ctv3 to the ac-code 
that appears in the archetype definition section, and no further constraint is 
given, the implication is that any code from any terminology with a binding may 
be used at runtime. Since this is normally on a value-set by value-set basis, 
each value set (each distinct ac-code) will have a binding entry only in those 
terminology groups in the binding section that make sense.

On 29/10/2015 15:31, Barnet David (HEALTH AND SOCIAL CARE INFORMATION CENTRE) 
wrote:
All
I have a modelling issue where I’m trying to bind a single data point or an 
archetype to a choice of terminology & code systems.

The actual use case is that I’m modelling a new-born hips examination, and the 
result may be given as either a SNOMED CT concept, a Read 2 code or a CTV3 code 
(for those unfamiliar with Read 2 & CTV3, they are code systems used (mostly) 
in primary care in the UK). In the actual instance, each code/concept will have 
a code system identifier to distinguish the actual code system used

For example, a result of “no abnormalities and no risk factors” can be 
represented as either

SNOMED CT

Read2

CTV3

ID

FSN

ID

Term

ID

Term

98570100100

Newborn and Infant Physical Examination Screening Programme, hip examination 
done, no abnormality and no risk factor

9OqJ1

NIPE hip, no abnor&no rsk fctr

XadAN

NIPE hip, no abnor&no rsk fctr


In the modelling tools I see you can have a choice, but I can’t see how the 
choice supports multiple terminologies. I see that it does support a choice of 
a terminology & Free text.

Is there a “standard” way of saying a data point may be represented by one of 3 
terminologies/codes systems? Or is this something the tooling deliberately 
stops you doing?

Thanks in advance

Dave Barnet
Interoperability Lead
Interoperability Specifications
Health & Social Care Information Centre
NHS in England



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

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

Re: Archetype publication question - implications for implementers

[Heath Frankel]

Thanks Ian for explaining the actual proposal.

I can't see why you can't add the dv_text to the location of measurement 
(opening the constraint). Then it just becomes an implementation choice to 
exclude the specific location inline with the new preferred model.

Regards

Heath

On 8 Oct 2015, at 8:26 pm, "Ian McNicoll" 
mailto:i...@freshehr.com>> wrote:

Hi Heath,

I think the suggested change was from

CLUSTER[at1033] occurrences matches {0..1} matches { -- Location
items cardinality matches {1..*; unordered} matches {
ELEMENT[at0014] occurrences matches {0..1} matches { -- Location of measurement
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0025, -- Right arm
at0026, -- Left arm
at0027, -- Right thigh
.
}
}
}
}
ELEMENT[at1034] occurrences matches {0..1} matches { -- Specific location
value matches {
DV_TEXT matches {*}
}
}
}
}

to

ELEMENT[at0014] occurrences matches {0..1} matches { -- Location of measurement
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0025,  -- Right arm
at0026,  -- Left arm
at0027,  -- Right thigh
. }
}
DV_TEXT 
matches {*} -- Specific location
}

which is how we would model it now.

As a side-note, ADL2.0 introduces the capacity to formally deprecate an 
existing node, which will be very helpful in these sort of situations.

I also favour adding the 'deg' unit to the existing Tilt quantity, as I think 
Sebastian suggested, as an alternative (and not making the change above). That 
would allow us to add the critical changes in a non-breaking manner.

Thanks to everyone who has contibuted so far - we still need other implementer 
views!!

Ian


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

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

On 8 October 2015 at 10:23, Heath Frankel 
mailto:heath.fran...@oceaninformatics.com>> 
wrote:
The existing versioning rules allow adding new concepts and opening constraints 
such as allowing additional units. These change the md5 hash but does require a 
version /id change.

This is why Sebastian's suggestion technically works, the existing obsolete 
concept still exists and the new concepts can be added for those that want to 
move to the preferred approach.

However, I am concerned about adding new concepts that are in fact the same as 
an existing just represented differently. This is why I suggested to add new 
units to the existing tilt element (opening the constraint) rather adding a new 
concept for tilt with the new units.

I also suggested adding the new representation for body site as a new concept 
but starting to think this is a bad idea since we are duplicating the concept 
and have two ways in the same archetype to represent the same concept and worse 
the concept has two identifiers.

Having said that I suspect the alternative representation is filling a slot 
with a cluster archetype in a template and hence there is no duplicate concepts 
in the same archetype, there is a new slot and the alternate representation is 
in a template instead. Is this any better? Perhaps marginally.

Regards

Heath

On 8 Oct 2015, at 6:42 pm, "David Moner" 
mailto:dam...@gmail.com>> wrote:


2015-10-08 1:23 GMT+02:00 Heather Leslie 
mailto:heather.les...@oceaninformatics.com>>:
It was Sebastian's suggestion about governing at an intra-archetype level that 
has caught my attention - marking an existing data element as outdated, and 
adding a new one as a revision solves the issue of having correct vs incorrect 
units and avoids the necessity of a new version immediately. I suggest we make 
this modification to the existing v1 and republish as stable (and technically 
correct).

But that will not be v1 anymore...

At this point, anyone who has worked for a time with the archetypes of CKM 
knows that the readable archetype ID, including the version number, it is not a 
reliable reference to identify the archetypes (this is said somewhere in the 
specifications, but should be more clearly stated for newcomers). The only 
reliable identifier from a technical point of view is the MD5 hash of the 
definition part of the archetype. Any change to the structure will create a 
different MD5. Any (correctly implemented) system that uses it will find that 
it is a new archetype, call it v1, v1+internal revision, v2 or whatever.

As Diego said, the less complicated solution is to just follow the versioning 
rules that already exist.

David

--
David Moner Cano
Grupo de Inform?tica Biom?

Re: Archetype publication question - implications for implementers

[Heath Frankel]

The existing versioning rules allow adding new concepts and opening constraints 
such as allowing additional units. These change the md5 hash but does require a 
version /id change.

This is why Sebastian's suggestion technically works, the existing obsolete 
concept still exists and the new concepts can be added for those that want to 
move to the preferred approach.

However, I am concerned about adding new concepts that are in fact the same as 
an existing just represented differently. This is why I suggested to add new 
units to the existing tilt element (opening the constraint) rather adding a new 
concept for tilt with the new units.

I also suggested adding the new representation for body site as a new concept 
but starting to think this is a bad idea since we are duplicating the concept 
and have two ways in the same archetype to represent the same concept and worse 
the concept has two identifiers.

Having said that I suspect the alternative representation is filling a slot 
with a cluster archetype in a template and hence there is no duplicate concepts 
in the same archetype, there is a new slot and the alternate representation is 
in a template instead. Is this any better? Perhaps marginally.

Regards

Heath

On 8 Oct 2015, at 6:42 pm, "David Moner" 
mailto:dam...@gmail.com>> wrote:


2015-10-08 1:23 GMT+02:00 Heather Leslie 
mailto:heather.les...@oceaninformatics.com>>:
It was Sebastian's suggestion about governing at an intra-archetype level that 
has caught my attention - marking an existing data element as outdated, and 
adding a new one as a revision solves the issue of having correct vs incorrect 
units and avoids the necessity of a new version immediately. I suggest we make 
this modification to the existing v1 and republish as stable (and technically 
correct).

But that will not be v1 anymore...

At this point, anyone who has worked for a time with the archetypes of CKM 
knows that the readable archetype ID, including the version number, it is not a 
reliable reference to identify the archetypes (this is said somewhere in the 
specifications, but should be more clearly stated for newcomers). The only 
reliable identifier from a technical point of view is the MD5 hash of the 
definition part of the archetype. Any change to the structure will create a 
different MD5. Any (correctly implemented) system that uses it will find that 
it is a new archetype, call it v1, v1+internal revision, v2 or whatever.

As Diego said, the less complicated solution is to just follow the versioning 
rules that already exist.

David

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

RE: Archetype publication question - implications for implementers

[Heath Frankel]

Hi Heather,
Although I agree with the idea of obsolete concepts, I wonder if it is 
necessary in this case of Tilt. Why can’t we just add the additional units as 
allowed options leaving the existing degrees symbol but in the element 
description indicate that this is obsolete and the correct units should be used 
instead.

The obsolete concept approach could be used for your body site improvement for 
example.

Regards

Heath

From: openEHR-implementers 
[mailto:openehr-implementers-boun...@lists.openehr.org] On Behalf Of Heather 
Leslie
Sent: Thursday, 8 October 2015 9:54 AM
To: For openEHR clinical discussions ; For 
openEHR technical discussions 
Cc: For openEHR implementation discussions 

Subject: RE: Archetype publication question - implications for implementers

Hi All,

It has been an interesting conversation. Many thanks for everyone’s input.

However, I think we do have a reasonable potential solution.

It was Sebastian’s suggestion about governing at an intra-archetype level that 
has caught my attention - marking an existing data element as outdated, and 
adding a new one as a revision solves the issue of having correct vs incorrect 
units and avoids the necessity of a new version immediately. I suggest we make 
this modification to the existing v1 and republish as stable (and technically 
correct).

The other breaking changes suggested are effectively ‘cosmetic’ in some ways – 
ie a more refined way to record the body site for the measurement that is 
congruent with the pattern that has evolved since the archetype was first 
published. And I suggest that we add this as a draft v2 – ie the way of the 
future.

Both archetypes can then be present in CKM – the published v1 and the newly 
proposed draft v2. Yes, there will be two atcodes related to ‘Tilt’ in the v1 
archetype – one for use, one outdated - but implementers who are using this 
data element will be able to make their own decisions on what to do internally; 
those implementations who don’t use the data element will be unaffected. This 
will minimise disruption to existing implementations, allow new vendors to use 
the correct v1 atocode in new implementations and we can then choose to review 
and publish the v2 at the time of our choosing.

Comments?

In principle, I think CKM has to be seen as the ‘source of truth’ wherever 
possible.

I really like this solution proposed by Sebastian as it offers us a way to 
govern that is finer grained than simply: draft vs published; v1 vs v2. We need 
to be mindful of this and use it as a more ‘delicate’ approach to our knowledge 
governance processes.

Regards

Heather

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Mikael Nyström
Sent: Thursday, 8 October 2015 4:27 AM
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>;
 For openEHR clinical discussions 
mailto:openehr-clini...@lists.openehr.org>>
Cc: For openEHR implementation discussions 
mailto:openehr-implement...@lists.openehr.org>>
Subject: RE: Archetype publication question - implications for implementers

Hi Ian,

I should probably clarify that the versioning mechanism in SNOMED CT is more 
than a technical thing. The versioning mechanism also includes guidelines about 
how to handle the changes in the receiving system. However, the guidelines are 
distributes in a form that is machine (and human) readable and processable, 
which might at a first look seem just to be a technical thing.

 Regards
 Mikael



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: den 7 oktober 2015 17:22
To: For openEHR clinical discussions
Cc: For openEHR technical discussions; For openEHR implementation discussions
Subject: Re: Archetype publication question - implications for implementers

Hi Vebjørn,

I hope I did not give the impression that I was in any way suggesting that the 
Norwegian clinical reviewers were being obscure or unreasonable and causing 
problems, or that tilt is not used in some applications. The review team have 
done exactly what we ask of them - to point out issues and errors and the 
'iconic' status of BP does not give it any special privileges :).

Just so that people understand this issue - the potentially breaking change in 
the BP archetype is that the unit of measure for the angle of Tilt is defined a 
degree symbol  =  °
which is the printable version of the UCUM unit and not the official UCUM unit 
which is  = DEG or deg.

If the Oslo University Arena implementation was perhaps 10 years down the 
track, with perhaps hundreds of thousands of BP records, including a small 
proportion with Tilt measurements using the ° unit already captured, it would 
be interesting to consider whether the cost of correcting this issue was felt 
to be worthwhile or whether we could 'live with' using the older version.

@Mikael - the capacity to re-version and

Re: difference and relationship between openEHR and EN13606

[Heath Frankel]

Technical, the original grammar for AQL was bound to openEHR RM classes, 
composition, version, observation, etc. theoretically it could be generalised 
to be a RM agnostic and should be the goal of the current AQL specification 
work if it hasn't already been done in the antlr grammar.

Regards

Heath

On 26 Aug 2015, at 9:40 pm, "Ian McNicoll" 
mailto:i...@freshehr.com>> wrote:

Hi Diego,

I was not aware of any 13606 implementations that support AQL , although I am 
sure there is some sort of path-based querying. AFAIK AQL is not part of the 
13606 scope.

Happy to be corrected.

Ian

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

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

On 26 August 2015 at 13:03, Diego Bosc? 
mailto:yamp...@gmail.com>> wrote:
I agree with most of the points, but I'm curious why you say that 13606 does 
not support AQL (and in any case wouldn't be "AQL does not support 13606"?)

2015-08-26 12:32 GMT+02:00 Ian McNicoll 
mailto:i...@freshehr.com>>:
This might help a little

http://www.slideshare.net/atalagk/implementation-and-use-of-iso-en-13606-and-openehr

Similarities:

Both use archetypes and ADL and two-level information modelling.
Both share the EHR, FOLDERS,COMPOSITIONS, ENTRY, ELEMENT classes.
Some archetype tools can work with both styles of archetype e.g LinkEHR and 
Archetype Workbench.
The just announced ADL2 Archetype editor/ template designer tools (beware!!! 
Early developer versions!!)

http://ehrscape.marand.si/designer/template-editor.html

http://ehrscape.marand.si/designer/archetype-editor.html

should be relatively easy to adapt to 13606 or other archetype-based reference 
models such as CIMI. They will be open sourced very soon.

Differences:

The EHR reference models are different
 In spite of sharing the classes above, the attributes within those classes 
differ
 openEHR sub-classes ENTRY into ADMIN_ENTRY, OBSERVATION, EVALUATION, 
INSTRUCTION and ACTION
 The datatypes are different

The demographic models are different
The EHR Extract formats are different

13606 is intended primarily for the communication of EHR extracts across 
systems but some persistence repositories exist.
openEHR is intended primarily for data persistence and querying within systems 
but it is possible to message openEHR data.

13606 does not (currently) support templates but ADL/AOM2 is being considered
13606 does not support AQL Archetype Query Language

13606 is  formal ISO standard but is closed source i.e. behind a paywall, as in 
normal for ISO published material
openEHR is open source and freely available

There is a great deal of cross-communication between the two communities and a 
number of people work with both formalisms. It is possible to transform data 
between the two formalisms but they are not directly compatible.

I hope that is accurate and non-contentious!

Ian





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

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

On 26 August 2015 at 10:14, ??? 
mailto:edwin_ue...@163.com>> wrote:
dear all ,
how could i  explain to someone difference and relationship between openEHR 
and EN13606
thx
--
???
15901958021



???1?

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


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


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

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

Re: VERSION.lifecycle_state options

[Heath Frankel]

#x27;. Other openEHR 
implementations may not need to use this 'final' feature if they allow in their 
versions may always be altered.

I'm ok to give (if necessary) a different name than 'final', as long it 
reflects the use case I described above. I'm also ok to make a compromise and 
use 'incomplete' where I actually need 'draft' (although I see it as two 
different meanings). Alternatively I could also use 'complete' instead of 
'draft' as long as I have and 'final' that pairs it.

@Heath: thanks for your examples and thoughts.

Regards,
Sebastian



On 6/11/2015 1:22 AM, Heath Frankel wrote:
Hi Sebastian,
To your general question, yes we needed something to indicate a version was 
moved distinct from deleted. This ensured that we couldn't undelete the 
version. There was a PR for this which included a new change type also.

To your usecases, I agree these are necessary but have concern about the term 
final. It doesn't seem to have the level meaning necessary for you use case as 
it is overloaded with pathology result status where a final can be corrected. 
Perhaps immutable is more specific. Similarly with draft, seems too similar to 
incomplete. What about unapproved or similar?

As with all out terminologies, having too many similar options makes it hard to 
select the correct one unless the usecases are very clearly specified. I think 
you have very distinct usecases, we just need to get the right term to ensure 
it best reflects the usecase.

Regards

Heath

On 11 Jun 2015, at 12:03 am, "Sebastian Iancu" 
mailto:sebast...@code24.nl>> wrote:

Hello all,

Does anybody (with an openEHR persistence system/solution) encountered the need 
to record other states than 'incomplete', complete', 'deleted' for a 
VERSION.lifecycle_state?

The use case is that in some circumstances a version need to become immutable 
and any change should be forbidden. Imagine a care plan that was already 
'inform-consented' - it should not be allowed to be changed in any way, neither 
logically deleted (unless perhaps some administrative reasons). In contrast, by 
current version of specifications, a 'complete' version can be still changed or 
logically-deleted (which is valid behavior also).

Regards,
Sebastian

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


--
Sebastian Iancu
mob: +31625588176 | email: 
sebast...@code24.nl<mailto:sebast...@code24.nl> | skype: sebastian_iancu
Code24 B.V.
Comeniusstraat 5, 1817MS Alkmaar, The Netherlands
www.code24.nl<http://www.code24.nl>


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

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



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



--
Sebastian Iancu
mob: +31625588176 | email: 
sebast...@code24.nl<mailto:sebast...@code24.nl> | skype: sebastian_iancu
Code24 B.V.
Comeniusstraat 5, 1817MS Alkmaar, The Netherlands
www.code24.nl<http://www.code24.nl>

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

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

Re: VERSION.lifecycle_state options

[Heath Frankel]

Hi Sebastian,
To your general question, yes we needed something to indicate a version was 
moved distinct from deleted. This ensured that we couldn't undelete the 
version. There was a PR for this which included a new change type also.

To your usecases, I agree these are necessary but have concern about the term 
final. It doesn't seem to have the level meaning necessary for you use case as 
it is overloaded with pathology result status where a final can be corrected. 
Perhaps immutable is more specific. Similarly with draft, seems too similar to 
incomplete. What about unapproved or similar?

As with all out terminologies, having too many similar options makes it hard to 
select the correct one unless the usecases are very clearly specified. I think 
you have very distinct usecases, we just need to get the right term to ensure 
it best reflects the usecase.

Regards

Heath

> On 11 Jun 2015, at 12:03 am, "Sebastian Iancu"  wrote:
> 
> Hello all,
> 
> Does anybody (with an openEHR persistence system/solution) encountered the 
> need to record other states than 'incomplete', complete', 'deleted' for a 
> VERSION.lifecycle_state?
> 
> The use case is that in some circumstances a version need to become immutable 
> and any change should be forbidden. Imagine a care plan that was already 
> 'inform-consented' - it should not be allowed to be changed in any way, 
> neither logically deleted (unless perhaps some administrative reasons). In 
> contrast, by current version of specifications, a 'complete' version can be 
> still changed or logically-deleted (which is valid behavior also).
> 
> Regards,
> Sebastian
> 
> ___
> 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

ACTION just as event trigger

[Heath Frankel]

Hi David,
I haven't been involved in the instruction/action modelling recently but I know 
that this principle of having the same item structure archetype girl the 
activity and action was preferred in the early days, it has recently deviated 
for some archetypes at least as the information requirements didn't align with 
this principle. I will leave it to the modellers to comment further.

I personally think that there should be more information in the action than the 
instruction but can also see the efficiencies of having minimal information in 
the action when an action can occur many times for any particular instruction. 
I guess it comes down to the the use case but my rule would be that only 
information that is common to all actions should go in the instruction 
otherwise you need to update the instruction as you go through the state 
transitions, which in my view is not desirable.

Regards

Heath

On 7 Apr 2015, at 7:07 pm, "David Moner" mailto:damoca at 
gmail.com>> wrote:

The recommendation is to always use the same archetypes you would have used to 
originally record that information. That is the best way to ensure the systems 
work when retrieving information. For example if you query about medications 
taken by the patient you only have to query the ACTION archetype instead of 
searching information scattered in other archetypes.

David


2015-04-07 11:19 GMT+02:00 pazospablo at hotmail.com mailto:pazospablo at hotmail.com>>:

Hi David. A medication taken should be an action or an observation? What 
matters more, the event of taking the drug ot yhat thr drug eas taken? I think 
the latter can occur when a doctor asks the patient for medication taken. I 
agree the real time record of the event can also occur.


Thanks!


Sent from my LG Mobile

-- Original message--

From: David Moner

Date: Tue, Apr 7, 2015 03:41

To: For openEHR clinical discussions;

Cc: openehr-technical at lists.openehr.org;

Subject:Re: ACTION just as event trigger

Hi Pablo,

Think that an ACTION can happen without any previous instruction. For example, 
a medication taken without a previous prescription. That information has to be 
stored not just as a log, but as proper clinical data. So it seems OK that 
ACTION includes part of the clinical record.

David

2015-04-07 4:06 GMT+02:00 pazospablo at 
hotmail.com mailto:pazospablo at hotmail.com>>:

A couple of week ago someone mebtioned that ACTION archetypes are not being 
developed or used a lot, and maybe is because we actually don't need to put 
data on ACTIONs as part of the clinical record, but maybe only as event trigger 
and logs of ehat happened. With tgis I mean: ACTION recording might be used ti 
send notifications to other statems (like whe a lab test is done, the results 
are sent or queried), or to keep the log of real world events that happened and 
may change the status of another entity (i.e. INSTRUCTION/ACTIVITY).


What is the opinion of the community about the role of the ACTION ENTRY in the 
openEHR Information Model and as a EHR entity, from the point of view of it's 
use in current systems?


Thanks,

Pablo.


Sent from my LG Mobile

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



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



--
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-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 

ACTION just as event trigger

[Heath Frankel]

Hi Pablo,
Actions are absolutely necessary and can carry different/additional information 
than the instruction.

An instruction is actually useless without an action. It is the action that 
puts the action into a particular state at a particular time. When an 
instruction is created it should also be accompanied with an action otherwise 
the instruction workflow is not yet invoked.

Take a medication ( I am not clinical so please excuse my ignorance but 
hopefully this demonstrates the intended technical solution), a clinical 
pathway may suggest a class of drug to be taken at a particular dosage, 
frequency and duration. This may be recommended by a decision support system by 
creating the instruction and an action to put it into the planned state. The 
doctor can then prescribe a generic drug using an action indicating particular 
form and strength and the state is transitioned to active with a care flow step 
of prescribed. Next the pharmacy dispenses the particular product and indicates 
administration instructions to the patient. The new action is still in active 
state but now has care flow step of dispensed, the time is the dispense time. 
The patient can now enter the administration of each dose, each action is an 
active step. Finally the system can optionally create a completed action when 
it determines each dies has been taken or the expires under some other criteria.

Personally I disagree with the original post indicating that action archetypes 
are not being developed of used a lot. They are absolutely essential in any 
system recording instructions such as our care planning systems. If they are 
not then there are fundamental misunderstandings of the instruction/action 
model.

Regards

Heath

On 7 Apr 2015, at 6:50 pm, "pazospablo at hotmail.com" mailto:pazospablo at hotmail.com>> 
wrote:


Hi David. A medication taken should be an action or an observation? What 
matters more, the event of taking the drug ot yhat thr drug eas taken? I think 
the latter can occur when a doctor asks the patient for medication taken. I 
agree the real time record of the event can also occur.


Thanks!


Sent from my LG Mobile

-- Original message--

From: David Moner

Date: Tue, Apr 7, 2015 03:41

To: For openEHR clinical discussions;

Cc: openehr-technical at lists.openehr.org;

Subject:Re: ACTION just as event trigger

Hi Pablo,

Think that an ACTION can happen without any previous instruction. For example, 
a medication taken without a previous prescription. That information has to be 
stored not just as a log, but as proper clinical data. So it seems OK that 
ACTION includes part of the clinical record.

David

2015-04-07 4:06 GMT+02:00 pazospablo at 
hotmail.com mailto:pazospablo at hotmail.com>>:

A couple of week ago someone mebtioned that ACTION archetypes are not being 
developed or used a lot, and maybe is because we actually don't need to put 
data on ACTIONs as part of the clinical record, but maybe only as event trigger 
and logs of ehat happened. With tgis I mean: ACTION recording might be used ti 
send notifications to other statems (like whe a lab test is done, the results 
are sent or queried), or to keep the log of real world events that happened and 
may change the status of another entity (i.e. INSTRUCTION/ACTIVITY).


What is the opinion of the community about the role of the ACTION ENTRY in the 
openEHR Information Model and as a EHR entity, from the point of view of it's 
use in current systems?


Thanks,

Pablo.


Sent from my LG Mobile

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



--
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-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 

Question concerning DV_EHR_URI

[Heath Frankel]

Have a look at the Architecture Overview, there is a section on paths and uris. 
Section 11 from memory.

Regards

Heath

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Kevin Keene
Sent: Thursday, 5 February 2015 8:07 PM
To: openeh technical; openEHR Clinical
Subject: Question concerning DV_EHR_URI

Hi all,

I had a question about the data type DV_EHR_URI. The specifications are a bit 
vague on this type:

http://www.openehr.org/local/releases/1.0.1/uml/Browsable/_9_0_76d0249_1109068357612_21665_4527Report.html

It only states that it should start with 'ehr'. How should an internal link to 
an object in an EHR look like? Are there any conventions, examples or ideas 
about that?

Thanks in advance,

Kevin Keene

This e-mail message is intended exclusively for the addressee(s). Please inform 
us immediately if you are not the addressee.
-- next part --
An HTML attachment was scrubbed...
URL: 

CRUD Restlet

[Heath Frankel]

The approach I took with my FHIR like API was to have a named query with know 
parameters and result columns. This could be registered internally using AQL or 
hard coded. This all comes from FHIR principles as they allow registering 
queries and then executing them.

Regards

Heath

On 20 Jan 2015, at 7:39 am, "Thomas Beale" mailto:thomas.beale at oceaninformatics.com>> wrote:

On 19/01/2015 21:01, Diego Bosc? wrote:
Sad to see that go away, I liked the idea of reusing well known formats for 
everything.
Regarding REST, I assume that nothing stops you to provide a method called 
"query" with the actual AQL query as a parameter :D

sure - but that forces the app programmer to develop AQL queries. Now, serious 
programmers and system builders have to do this, but it's not unreasonable to 
minimise it, especially for common cases, and to help devs who may not be PhDs 
in openEHR, AQL, archetypes etc. So where can we help them? Well the FHIR 
approach is trying to hit that kind of sweet spot. The ideal version of FHIR or 
a FHIR-like approach, that we can work on in openEHR is to be able to generate 
directly from the archetype model-base FHIR profiles (and probably even some 
resources).

- thomas


2015-01-19 21:58 GMT+01:00 Thomas Beale mailto:thomas.beale at oceaninformatics.com>>:

I would agree with Isabel.

Not everything is a resource, or should be seen as a resource. If you just want 
to pull back a lump of data, that could be a 'resource', and for that a REST 
service based on FHIR or some other API will make sense. Resource-oriented 
stateless services are suited to some kinds of applications, mostly readers in 
my view.

A service for talking directly to an EHR data store (i.e. a CDR) could be 
designed as a REST service in theory, but it's not that well matched to the 
kind of service interface of pattern of calls that will be made (especially if 
distributed queries and commits are to be supported).

The interesting question is: what style of service should be used for e-health 
business entities, like active care plans, managed medication lists, and order 
management, which all need much more complex APIs than just 'get'? FHIR is not 
designed for this kind of thing, and it's questionable whether REST is either. 
The APIs in these cases need to be carefully designed, and could easily be 
stateful / session-oriented - especially if they manage a shared resource that 
multiple agents may try to update simultaneously. In any case, I don't see 
statefulness or not as the decider on what kind of protocol you want; structure 
is a bigger decider.

I think it's easy to fall into the trap of thinking a single latest / 
fashionable protocol is good for all layers of a complex architecture. That's 
very unlikely to be true. I see no problem with an complete solution having 
REST, SOAP, binary RPC and other kinds of interfaces.

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

CRUD Restlet

[Heath Frankel]

I too have looked how the approach used by FHIR could be applied generically to 
openEHR, but at the entry level using TDDs. I actually went up one level and 
considered the principals of the HL7-OMG RLUS specification, which is the 
logical basis of FHIR before they hard coded the resources. RLUS also has a 
SOAP based interface.

The spec I wrote for this is being consider for implementation by three vendors 
as part of a single project, they chose the SOAP binding rather than REST (REST 
is not for everyone). Will be interesting if it happens.

Regards

Heath

> On 19 Jan 2015, at 9:00 pm, "Diego Bosc?"  wrote:
> 
> I will just add that if you are making a server you probably want to
> take a look and how FHIR does things. They have some pretty cool ideas
> for common problems that you can probably reuse (e.g. using atom for
> query responses)
> 
> 2015-01-19 11:25 GMT+01:00 Seref Arikan  kurumsalteknoloji.com>:
>> I've managed not to respond for some time but this discussion got to a point
>> where I can't help commenting :)
>> 
>> REST is a fact of the industry, due to whatever mysterious dynamics that
>> pushes various solutions down our throat as we get old in front of our
>> computers. So we live with it.
>> 
>> This does not change the fact that trying to push complex shaped objects
>> through a few holes shaped as a rectangle, circle and a triangle will leave
>> some parts of those objects broken. Then we have people discussing for ages
>> what the right verb mapping would be for an operation. If you try to express
>> an infinite number of API calls and their semantics with a bunch of HTTP
>> operations and status codes, this is what you get.
>> 
>> REST may make things easy for some use cases, but do complex use cases in
>> healthcare fall into that category? I should probably look at Erik's
>> research at one point but my dislike for being forced to express semantics
>> with a very limited number of some text transfer protocol based concepts
>> will not go away.
>> 
>> Best regards
>> Seref
>> 
>> 
>>> On Mon, Jan 19, 2015 at 5:59 AM, Bert Verhees  
>>> wrote:
>>> 
>>> I checked on how the large companies like Google, Amazon, PayPal, github
>>> do it.
>>> 
>>> They all have a hybrid solution. They all use an own error schema was
>>> verbal terms, sometimes hierarchical, and they all map their errors to the
>>> http numerical status schema.
>>> 
>>> This means that a query with no result is qualified as a 404 error.
>>> However this seems unlogical to me, is that how the big guys it do. It is
>>> the same error which is fired when you try to call a non existing method.
>>> But the accompanying message is different.
>>> 
>>> It is difficult for me to qualify a query which has no result as an error.
>>> Have you ever been sick? No? That is a 404 error.
>>> 
>>> But on the other hand, that is how the big guys do it.
>>> 
>>> Bert
>>> 
>>> Op maandag 19 januari 2015 heeft Bert Verhees  het
>>> volgende geschreven:
>>> 
 Ok, you are right, but http is a very generic application layer, not to
 designed to serve specific application needs, but designed to serve web
 servers which only serve documents.
 As you know, a web server is a very generic application, which, from the
 time Http was designed, was only recource driven.
 
 Maybe the error is that Rest uses a generic application layer which is
 defined as a resource driven application layer, but in fact Rest is used as
 a service oriented application protocol. I think that an OpenEhr kernel, or
 PayPal-service, or many other Rest using applications are also service
 oriented, not only resource oriented, and that therefor, a resource 
 oriented
 error handling is unable to serve the needs of a service oriented
 application.
 
 You could call that misusing http, because it was not designed for that,
 but on the other hand, with some new thinking, Http can be used to serve a
 service oriented architecture. Or do you not agree with this statement?
 
 By the way, nowhere is written that Rest must use the Http status
 mechanism for communicating application needs. It is written that Rest must
 used http statuses for http-needs, and Restlet does do that.
 
 best regards
 Bert
 
 Op maandag 19 januari 2015 heeft Peter Gummer
  het volgende geschreven:
> 
> Bert Verhees wrote:
> 
>> The point for me is separation of transport layer and application
>> layer, and each domain has its own errorhandling.
> 
> 
> 
> Hi Bert,
> 
> HTTP is not a transport layer protocol:
> 
> http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
> 
> ?The Hypertext Transfer Protocol (HTTP) is an application protocol ?"
> 
> Thanks for the discussion, though. I?ve learned a lot from it.
> 
> Peter
 
 
 
 --
 This e-mail message is intended exclusively for the addressee(s).
>>>

openEHR-technical Digest, Vol 35, Issue 33

[Heath Frankel]

Hi Tom,
In fact this was demonstrated at MIE in 2007 and again at least once if not 
twice at HIC as part of IHE showcase that included storing the result in the GE 
XDS. Chris Lindop and other HL7 members were involved in the overall showcase 
so they new it existed for real.

This had nothing to do with NEHTA but we certainly discussed with them and they 
still ask questions every now and then.

It is likely that we will be doing thus in a production system in the not to 
distant future depending in what a receiving system wants to receive. Whenever 
we have discussed with a customer/vendor the options to use CDA or TDD/openEHR, 
the later is chosen.

If HL7 people asked for it then they asked the wrong people. I guess they 
didn't really want to know about it.

Heath




 Original Message 
Subject: Re: openEHR-technical Digest, Vol 35, Issue 33
From: Thomas Beale 
To: "openehr-technical at lists.openehr.org" 
CC:


HI William,

I know for a fact that archetype-based CDAs do/did exist, because Ocean
built them for Nehta (not many though, it's not that easy to do it).
However, Nehta is notoriously sensitive with IP, and may well have
refused them to be made public. I have also seen some other technical
solutions, something like proof-of-concept level solutions with CDA
containing archetyped data; none of these was operationalised (it was
done in Aus and UK).

I have no idea if any of these are alive today, or even relevant. So at
a practical level, you may be right ;-)

I suspect the only place to get any serious CDA templates at all is MDHT
/ VHA. I have no idea on the current status there though.

By the way, in case you are interested, we will have single-file ADL 2
templates demonstrable in the next ADL Workbench, and I will post some
early information / screen shots here imminently.

- thomas

On 20/01/2015 16:27, William Goossen wrote:
> Someone in the OpenEHR world created a nice CDA that uses archetypes. It was
> presented at several meetings in the HL7 space, in particular in the patient
> care workgroup.
>
> However, it was a powerpoint. The HL7 people asked for the ppt, but that was
> never delivered.
> The HL7 people asked the openEHR example of CDA with archetypes, but that
> was never delivered.
>
> So the solution was told to be exist (CDA filled with archetypes), but not
> made available. So it in fact does not exist.
>
> The world of CDA around the world talks a lot about templates. In all IGs
> there are specs how such a template should / would look.
>
> But after 15 years since the conceptualization of HL7 templates, these are
> non existent. (I mean not findable even to insiders).
>


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

Finalising archetype meta-data

[Heath Frankel]

Hi Thomas,
I am not sure why we can't use other-details for all of these. It doesn't seem 
critical for processing archetypes, it is only for reference.

Regards

Heath

On 21 Nov 2014, at 1:21 am, "Thomas Beale" mailto:thomas.beale at oceaninformatics.com>> wrote:


There is a test archetype here 

 that shows an example of proposed new meta-data items.

Things to notice:

  *   'rm_release=1.0.2' in the top line. Rm_release is now a mandatory item in 
ADL 2 (but easy to synthesise in converters)
  *   'copyright' is now at the outer level, before it was in the translatable 
part, i.e. with 'keywords' etc - now there is only one copyright statement for 
an archetype
  *   'licence' is a new item
  *   there are items for 'original_xxx' and 'custodian_xxx' intended to 
document the original organisation that created something, and the current 
custodian of that thing.
  *   proposed new blocks for 'ip_acknowledgements' and 'conversion_details'

A question I have is: are the items for original publisher / namespace and 
custodian organisation enough?

Currently they are as follows:

original_namespace = <"org.archetypes-r-us">
original_publisher = <"Archetypes R Us">
custodian_namespace = <"org.openehr">
custodian_organisation = <"openEHR Foundation">

However, if we thing we need any more items for these two, we are stuck with 
this model - the only place we could put new items would be in the main 
'other_details' block. Should we instead do the following:

original_publisher = <
organisation = <"Archetypes R Us">
namespace = <"org.archetypes-r-us">
other_details = <
["key"] = <"value">
["key"] = <"value">
...
>
>
custodian = <
organisation = <"openEHR Foundation">
namespace = <"org.openehr">
other_details = <
["key"] = <"value">
["key"] = <"value">
...
>
>


This is only slightly more complex, but much more flexible. As we are 
finalising the ADL/AOM 2 specifications, this is one of the last issues, so now 
is a good time to decide if we need to change this.

It is worth noting that we have done the ip_acknowledgements and 
conversion_details (both imminently needed by CIMI) differently:

ip_acknowledgements = <
["loinc"] = <"This content from LOINC(r) is copyright (c) 1995 
Regenstrief Institute, Inc. and the LOINC Committee, and available at no cost 
under the license at http://loinc.org/terms-of-use";>
["snomedct"] = <"xyz">
>
conversion_details = <
["source_model"] = <"CEM xyz 
">
["tool"] = <"cem2adl v6.3.0">
["time"] = <"2014-11-03T09:05:00">
>

This is because in the first case, the structure is logically a keyed list of 
values, where we never know the keys, and in the 'conversion_details' case, 
because we are not currently sure of the keys (and maybe we'll never have 
standard keys for that).

- thomas

___
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 

Doctor specialty in the IM

[Heath Frankel]

Hi Pablo,
I too have this requirement but more specifically I need the speciality of the 
composer that he was performing at the time of writing the composition. 
Therefore option 2 is not viable as this may change over time and the clinician 
may have multiple specialities and they may not even be applicable to the one 
he was performing at the time of being the composer.

I am not keen on option 1 as you need to somehow correlate a participation with 
the composer and we have to replicate what is already specified in the composer 
just to specify the function.

Ideally a speciality attribute should be provided on the composer but that 
would be a RM change.

I think your other_context option is the best available option, but in the 
interest of alignment I would like to get agreement on this, perhaps by 
collaborating on a cluster archetype for author details to be used in the other 
context structure and make this available on CKM.

I actually have some other othercontext archetypes that maybe useful to others 
but unfortunately I don't understand the process on how a techie like me can 
contribute archetypes to CKM that I use in real project because I am not a 
"clinical" modeller.

Regards

Heath

On 7 Nov 2014, at 1:54 pm, "pablo pazos" mailto:pazospablo at hotmail.com>> wrote:

Thanks Thomas,

For this requirement I need to query documents by attending physician 
specialty, so in the 2nd option I'll need to query the demographic server to 
get the ids of the physicians with specialty X, then find the records for 
patient Y with composer contained in that list of physicians.

Of course this is a pretty naive implementation, in this case I would have 
indexes of compositions by specialty, something I can create when the 
composition is committed to the EHR server, then this kind of query will use 
those indexes to avoid the "manual" join between demographic and ehr models.

Yep, the 3rd will need archetyped other_context. Thinking out loud, this kind 
of solution can help on enabling this kind of query by specialty to be 
implemented as AQL, so there will be no need to add another service endpoint to 
the API (thinking of my implementation).

Thanks again!

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


Date: Thu, 6 Nov 2014 16:08:01 +
From: thomas.beale at 
oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: Doctor specialty in the IM


Hi Pablo,

the first is as good as any. Normally PARTICIPATION.function is intended to 
capture the function of the physician in the activity, which could be general 
or specific. It might not be the same as the specialty of the doc, especially 
if that specialsiation is not implicated in this activity.

It makes sense to do 2 if you are already using openEHR demographics, because 
then you can use PARTY_PROXY.external_ref to point to the PARTY in the provider 
DB, and that will have the specialty, and then the participation can be 
something more specific. E.g. a senior surgeon might be an 'assisting 
physician' at a difficult birth being managed by the primary Obstetrician of 
the patient.

I don't think you need to query the demographic DB, just refer to the object, 
unless you actually need to have the specialty in the EHR data.

Option 3 is probably only sensible if it is archetyped that way - otherwise 
noone will expect that info in the context object. But you need to look at how 
clinical people are using the context structure (i.e. look at some Composition 
archetypes) - maybe they are putting this sort of information in there.

- thomas

On 06/11/2014 15:50, pablo pazos wrote:
Hi, I have a small question: if I need to record the specialty of an attending 
doctor:

1. Should I use the PARTICIPATION.function attribute?
2. Another option is to have that in the CAPABILITY.credentials from the 
demographic model.
3. And a third option I can think of is to use EVENT_CONTEXT.other_context 
structure.
4. Other?

My idea is to let users to find records by the specialty of the composer.

In the 1st option I need to create a PARTICIPATION for the composer so I can 
use the "function" attr.
In the 2nd option, the problem is I need to query the demographic server to get 
the specialty.
In the 3rd option I need to create a custom archetype to give structure to the 
generic "other_context" ITEM_STRUCTURE.




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

Archetype Naming proposals - do we need V0?

[Heath Frankel]

I completely agree with this,
The number one priority is that all existing clinical data using archetypes 
published in CKM for the last 2-5 years is not Invalidated by this process. I 
understand that it was use at your own risk but surely vendors that have taken 
the risk to be early adopters get some support by the foundation.

I think we need to keep all archetypes in CKM as they are unless there is 
evidence that no one is using a particular archetype. They must be treated with 
the same status of published as new ones, they have passed the test of time and 
more importantly the test of implementation.

I see no problem with starting with v2 for the next iteration.

Regards

Heath

> On 7 Oct 2014, at 2:02 am, "Bo?tjan Lah"  wrote:
> 
> Hi everybody,
> 
> sorry for not jumping in this earlier...
> 
> We (Marand) are looking at this from a vendor point of view much like 
> Sebastian from Code24. We have quite a bit of existing data, apps with AQLs, 
> etc.
> 
> Now if I understood everything correctly we have two ways:
> - existing archetypes would initially change from v1 to v0.* something and 
> once published would become v1.0.0
> - existing archetypes would initially change from v1 to v1.0.0-unstable (or 
> -alpha - to be decided) and once published would become v1.0.0
> 
> I have no problem with either style and think both would work equally well.
> 
> But this is not the only change - we would also add namespace to ids so final 
> (published) full archetype id would be:
> org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.0
> which includes namespace as well as new full version number.
> 
> So this makes change anyway much larger and needs to be tackled no matter if 
> versions in CKM now go to v0 or to v1*-alpha. 
> Even though archetype id will in fact not change in ADL1.4, other_details 
> will carry all the rest and we can already start using it. 
> 
> The question is - does it make sense to start using it while our whole stack 
> is still on ADL1.4 as it affects quite a few things:
> - existing stored RM data
> - RM paths - this might be in AQLs or other tools that use such paths
> 
> I would think this is too much hassle and would probably change to new 
> versioning only when we also support ADL2.
> 
> The only danger I see with this is that we'd suddenly have existing archetype 
> ids in the system with openEHR-EHR-OBSERVATION.lab_test.v1 which in CKM might 
> be completely different due to them going though the release process (back to 
> v0* or v1...-unstable) and finally becoming 
> org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.0.
> This case would indeed be solved by releasing them as v2.0.0 instead of 
> v1.0.0 - perhaps this can be on case-by-case basis - I assume not all 
> archetypes in the sprint will change in an incompatible way?
> 
> Best regards,
> --
> Bostjan Lah
> Marand d.o.o.
> 
>> On 5 Oct 2014, at 21:03, Sebastian Iancu  wrote:
>> 
>> On 10/3/2014 5:40 PM, Ian McNicoll wrote:
>> 
>> Hi Ian,
>> 
>>> Hi Sebastian,
>>> 
>>> Many thanks for your input. Your contribution is particularly important as 
>>> Code24 is, as you say,  one of the early pioneers of managing openEHR data 
>>> and related artefacts.
>>> 
>>> You have raised an important and very real issue, but I agree with 
>>> Sebastian Garde that the .V0 question itself, is actually not what is going 
>>> to potentially cause you a problem.
>>> 
>>> Firstly I would defend what has been done in CKM to date as being 
>>> completely in line with the specs and with the revisioning rules (which 
>>> actually have worked extremely well for published archetypes). It has 
>>> always been clear that any archetypes not marked as 'published' must be 
>>> considered unstable and cannot be guaranteed to follow the numbering rules. 
>>> I understand why you might take a view that 'anything that appears in CKM 
>>> is de-facto published' but that is not, and never will be the case. CKM is 
>>> first and foremost a clinical review environment which will always contain 
>>> a mix of draft, published, re-draft and re-publshed archetypes.
>>> 
>>> Having said all that, none of us are happy that it has take so long to get 
>>> to a stage where we could get sufficient resource to properly fund 
>>> editorial resource to take many archetypes through to publication though 
>>> thankfully, through the Industry Sprint that point has now arrived. I am 
>>> also familiar with  and have sympathy for the issue you have raised which I 
>>> will try to elucidate here, as I agree with Sebastian that it is a separate 
>>> issue from V0.
>>> 
>>> Your current situation is that you have used .v1 archetypes in your 
>>> production system, even though they are marked as 'draft' in the metadata 
>>> and by definition will have unstable structures leading to a situation 
>>> where ongoing draft development and eventual publication of the draft v1 
>>> archetype may well break existing query paths in your patient data and in 
>>> related code and qu

Commits and Contributions

[Heath Frankel]

The commit uid is generated by the ocean EHR client, this is consistent with a 
git commit. All this is is a GUID so easy to do. Although I set the commit time 
on the client, I override this on server.

Heath




 Original Message 
Subject: Commits and Contributions
From: pablo pazos 
To: openeh technical 
CC:

Hi, I'm working on EHRServer, trying to improve how the XML is committed and 
processed to simplify querying.

Right now I have a web app that commits a list of VERSIONs to the EHRServer. 
That service is based on the Ocean's commitContribution service 
http://www.openehr.org/wiki/display/spec/Ocean+Informatics+EHR+Service+Interface

The CONTRIBUTION instance for the committed VERSIONs is created by the 
EHRServer, but the VERSIONs come in XML format. Looking at the openEHR XSDs, 
each VERSION needs an OBJECT_REF to a CONTRIBUTION. Since the CONTRIBUTION is 
created by the EHRServer, the VERSION XML doesn't have the OBJECT_REF, so it's 
invalid against the openEHR XSDs.


What can I do?

1. Create the CONTRIBUTION at the client side and commit both, CONTRIBUTION and 
VERSIONs.
2. Add dummy XML to each VERSION just to pass the XSD validation.
3. Modify the openEHR schemas to add minOccurs=0 to the version.contribution 
element.
4. Other?


Why I think these solutions are not so good:

1. IMO the role of the server is to create the CONTRIBUTION, because it's like 
a log for the commit, also the Ocean's service doesn't receive a CONTRIBUTION 
object.
2. I don't like adding stuff I will not use but seems the less problematic 
solution.
3. For me this is terrible, I want to play with the openEHR rules, not make my 
own, but it is just for the commit, so if I want to send compositions to an 
external system, that will be valid against the original openEHR XSDs because 
in the EHRServer I have the CONTRIBUTION.


What do you think? Do you have a better solution? Thanks!

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com
-- next part --
An HTML attachment was scrubbed...
URL: 

Small question about commits and AUDIT_DETAILS.system_id

[Heath Frankel]

Hi Pablo,
No I don't agree. The point I tried to explain was that the system is the EHR 
repository, not an application. So if there is one or more applications using a 
repository at one or more organisations the is just one system id.

In an Australian jurisdiction I have a repository that is used by multiple 
instances of 5 applications at 100 diff healthcare facilities managed by gov't 
and non gov't organisations. There is only one system id for the repository.

Heath




 Original Message 
Subject: RE: Small question about commits and AUDIT_DETAILS.system_id
From: pablo pazos 
To: openeh technical 
CC:

Hi! Thanks for your answers.

It is a little tricky but from Thomas comments, I think that the "system" is 
not a technical term, but is more related to an organizational term. For 
example, if I use the same system / service to hold EHRs from 2 different 
hospitals, I really have 2 system ids instead of one. So the system_id doesn't 
depend on the technical architecture, but depends on how the business is 
organized. Is that correct?

Again, the description from the specs doesn't help to understand this 
("Identity of the system where the change was committed", so it depends on what 
a "system" is for us).

For the next version of the specs I think we can update that description and 
maybe give a couple of examples.

What do you think?

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos>


Date: Thu, 21 Aug 2014 09:47:35 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: Small question about commits and AUDIT_DETAILS.system_id


Heath,

this is correct, you were not wrong for 10 y ;-)

We don't record the name or type or id of the application, and I am not sure 
even now if that would be of any use. I can't see that it would be. The 
system_id is for exactly the purpose that Heath as explained here.

- thomas


On 21/08/2014 00:27, Heath Frankel wrote:

Hi Thomas & Pablo,

I am finding the words in the this discussion ambiguous, and the specification 
does help to clarify. Here is my interpretation of AUDIT_DETAILS.system_id.



I have an EHR service, which is used by two different application, one is a 
hospital system and another a mobile application that may not be related to the 
hospital system but share the same EHR service. When the hospital system and 
mobile application commits something they are using the same system_id, the 
system_id of the EHR service. If there is an exchange of data between this EHR 
service and another organisations EHR service via an EHR extract, the system ID 
will be used in the other organisations EHR service to identify that the commit 
was performed in the original organisations system_id.



Therefore, the system_id identifies the system that is assigning version 
identifiers in the EHR repository, i.e. the AUDIT_DETAILS.system_id matches the 
system_id component of the version.uid. This is important for distributed 
versioning.



So in Pablo?s scenario, it is one system of multiple components with multiple 
components sharing the same EHR service, the mobile and the EMR would use the 
same system_id.



Has my interpretation been wrong for 10 years? If so, then we need clarity 
added to the specification.




___ 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/20140907/cbf0d0ed/attachment.html>

Small question about commits and AUDIT_DETAILS.system_id

[Heath Frankel]

Hi Thomas & Pablo,
I am finding the words in the this discussion ambiguous, and the specification 
does help to clarify. Here is my interpretation of AUDIT_DETAILS.system_id.

I have an EHR service, which is used by two different application, one is a 
hospital system and another a mobile application that may not be related to the 
hospital system but share the same EHR service. When the hospital system and 
mobile application commits something they are using the same system_id, the 
system_id of the EHR service. If there is an exchange of data between this EHR 
service and another organisations EHR service via an EHR extract, the system ID 
will be used in the other organisations EHR service to identify that the commit 
was performed in the original organisations system_id.

Therefore, the system_id identifies the system that is assigning version 
identifiers in the EHR repository, i.e. the AUDIT_DETAILS.system_id matches the 
system_id component of the version.uid. This is important for distributed 
versioning.

So in Pablo's scenario, it is one system of multiple components with multiple 
components sharing the same EHR service, the mobile and the EMR would use the 
same system_id.

Has my interpretation been wrong for 10 years? If so, then we need clarity 
added to the specification.

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, 21 August 2014 2:05 AM
To: openehr-technical at lists.openehr.org
Subject: Re: Small question about commits and AUDIT_DETAILS.system_id


Hi Pablo,

the original idea is that it is an id more like "emr1.my_domain.uy" - i.e. an 
actual host domain, so if the data are copied or moved elsewhere, the receiver 
knows the original EMR system that the data were created on.

- thomas

On 20/08/2014 17:25, pablo pazos wrote:
Hi,

I'm reviewing the common_im specs, and the description for 
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".

I have an architecture like this:

EMR: data input, transactional, specific for 1 medical specialty
Mobile APP: data input, transactional, for patient data input
EHR: where commits are done to the patient EHR from EMR, Mobile APP and other 
systems

All the system together (EHR, EMR, Mobile APP) is called E-EHR.

What should I use as the CONTRIBUTION.audit.system_id when the EHR gets commits 
from EMR and Mobile APP?
("EHR"? "EMR"/"Mobile APP"?, "E-EHR"?).

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

Ocean's Template Designer and allowedType rules

[Heath Frankel]

Hi Shinji,
Can you be more specific about your question? 

Heath

-Original Message-
From: openEHR-implementers
[mailto:openehr-implementers-bounces at lists.openehr.org] On Behalf Of Shinji
KOBAYASHI
Sent: Friday, 15 November 2013 12:26 PM
To: For openEHR implementation discussions
Cc: For openEHR technical discussions
Subject: Re: Ocean's Template Designer and allowedType rules

Hi Heath,

I have a related question about OPT.
Could you explain path calculation algorithm for OPT?

Best wishes,
Shinji KOBAYASHI

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

___
openEHR-implementers mailing list
openEHR-implementers at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr
.org

Ocean's Template Designer and allowedType rules

[Heath Frankel]

Hi Pablo,

The OET format is an internal format. You should export the template as an
OPT and you will get a AOM and RM based output.

 

Heath

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of pablo pazos
Sent: Friday, 15 November 2013 1:06 AM
To: openeh technical; openehr implementers
Subject: Ocean's Template Designer and allowedType rules

 

Hi all,

 

I'm playing with the TD v2.7.60Beta to include openEHR template support to
CaboLabs EHRServer (http://www.youtube.com/watch?v=D-hs-Ofb8SY)

 

I opened the Blood Pressure archetype and tryied to constraint the Any Event
node of type EVENT to allow only POINT_EVENT, and I get this rule:

 

   

  

PointInTime

  



 

Shouldn't "PointInTime" be "POINT_EVENT"?

 

Is there any reason for the TD to not use openEHR datatype names?

 

Where can I find all the names used to constraint allowedTypes in TD?

 

Thanks!


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

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

Instruction archetypes and overlaping nodes with INSTRUCTION.narrative

[Heath Frankel]

Hi Ian,

Looking in the openEHR CKM there are several instruction archetypes that
don?t require an ACTIVITY occurrence (0..1 or 0..*) including Medication
order and Non-drug therapy. Therefore you can have a Medication order with
only a narrative and no structured data.

 

Heath

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Ian McNicoll
Sent: Wednesday, 30 October 2013 10:51 AM
To: For openEHR technical discussions
Subject: Re: Instruction archetypes and overlaping nodes with
INSTRUCTION.narrative

 

Hi Heath

 

Do you have a specific example where the associated archetype does not have
an element which could carry the unstructured narrative ? 


Ian

 

Dr Ian McNicoll

Clinical modelling consultant Ocean Informatics

Mobile +44 (0) 775 209 7859

Skype imcnicoll


On 29 Oct 2013, at 23:40, Heath Frankel 
wrote:

I agree with Anne?s cases based on my experience. Keep in mind that the
structured data is optional and that the narrative may be all we have.

 

Heath

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Ann Wrightson (NWIS - Enterprise Architecture)
Sent: Tuesday, 29 October 2013 10:38 PM
To: For openEHR technical discussions
Subject: RE: Instruction archetypes and overlaping nodes with
INSTRUCTION.narrative

 

A slightly different angle from Thomas? response, from my implementation
experience in similar situations:

 

There are two clear ?base cases?:

 

1.   If there is a comprehensive narrative entered by a human then that
is the narrative, i.e.  any structured or coded data is regarded as
supplementary machine-readable content.

2.   If there is structured data without a narrative, then as Ian
describes a human readable narrative is constructed from the data.

 

In practice, I would expect a fair bit of discussion around these options
with the lead clinical users who assure and accept a particular solution (&
often a formal patient safety review too). As a result of such
discussion-in-context, a hybrid solution may be preferred where for example
the narrative as entered is shown first, followed by an algorithmic textual
rendering of key data items for patient safety such as medications.

Regards,

Ann W.

Ann M Wrightson
Pensaer TG | Lead Technical Design Architect
Gwasanaeth Gwybodeg GIG Cymru | NHS Wales Informatics Service
Caernarfon: Ff?n/Tel:   01286 674226   Pencoed: WHTN: 01808 8940
Ff?n/Tel: 01656 778940
Symudol/Mobile: 07535 481797

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Thomas Beale
Sent: 29 October 2013 11:34
To: openehr-technical at lists.openehr.org
Subject: Re: Instruction archetypes and overlaping nodes with
INSTRUCTION.narrative

 


I knew that question was coming ;-) 

Firstly, how would you detect an inconsistency? It can only be done by a
human being, or else a quite sophisticated piece of software. Now, what does
it mean if there is a difference?

Firstly they are not quite 'duplicates'. The narrative is a directive to a
human agent to do something, in a slightly coded language that is supposed
to be understood unambiguously by the author and the reader.

The structured representation is just that - a structure representing the
medication order activities, timing etc.

If they don't say the same thing it could mean:

*   the software that created the structural representation has an
error, and creates structures different from the clinical intention
*   the software that created the narrative has an error, and created a
different text from that required by the clinician

As for any other data in the record, there is no 100% guarantee that any of
it is right. The correct comparison is not just between the two, but between
both of them and the original clinical intention, which is the reference.
This comparison will only be made during testing, where the purpose is to
ensure the software is bug-free.

In routine use, inconsistencies probably won't be detected - the doctor will
just assume the software works properly. So it's just a question of making
sure the software works properly...

- thomas


On 29/10/2013 10:07, Diego Bosc? wrote:

And if an inconsistency is detected, which one is supposed to be right?

 

2013/10/29 Thomas Beale 


Just to re-iterate, the 'narrative' property is meant to carry the piece of
text that would appear on a medication or with a medication as supplied by a
pharmacy (including in a hospital). When the administering agent is a human
- the patient, family member or a nurse - this is normally the concrete
direction that is followed. 

The computable form of the order / instruction says the same thing, but in a
computable form, allowing structured querying, analysis, all the usual
stuff.

This is probably the only place where there is content duplication in
openEHR, and as far as I can see, it needs to be like that, since there is
no stan

Instruction archetypes and overlaping nodes with INSTRUCTION.narrative

[Heath Frankel]

I agree with Anne?s cases based on my experience. Keep in mind that the
structured data is optional and that the narrative may be all we have.

 

Heath

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Ann Wrightson (NWIS - Enterprise Architecture)
Sent: Tuesday, 29 October 2013 10:38 PM
To: For openEHR technical discussions
Subject: RE: Instruction archetypes and overlaping nodes with
INSTRUCTION.narrative

 

A slightly different angle from Thomas? response, from my implementation
experience in similar situations:

 

There are two clear ?base cases?:

 

1.   If there is a comprehensive narrative entered by a human then that
is the narrative, i.e.  any structured or coded data is regarded as
supplementary machine-readable content.

2.   If there is structured data without a narrative, then as Ian
describes a human readable narrative is constructed from the data.

 

In practice, I would expect a fair bit of discussion around these options
with the lead clinical users who assure and accept a particular solution (&
often a formal patient safety review too). As a result of such
discussion-in-context, a hybrid solution may be preferred where for example
the narrative as entered is shown first, followed by an algorithmic textual
rendering of key data items for patient safety such as medications.

Regards,

Ann W.

Ann M Wrightson
Pensaer TG | Lead Technical Design Architect
Gwasanaeth Gwybodeg GIG Cymru | NHS Wales Informatics Service
Caernarfon: Ff?n/Tel:   01286 674226   Pencoed: WHTN: 01808 8940
Ff?n/Tel: 01656 778940
Symudol/Mobile: 07535 481797

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Thomas Beale
Sent: 29 October 2013 11:34
To: openehr-technical at lists.openehr.org
Subject: Re: Instruction archetypes and overlaping nodes with
INSTRUCTION.narrative

 


I knew that question was coming ;-) 

Firstly, how would you detect an inconsistency? It can only be done by a
human being, or else a quite sophisticated piece of software. Now, what does
it mean if there is a difference?

Firstly they are not quite 'duplicates'. The narrative is a directive to a
human agent to do something, in a slightly coded language that is supposed
to be understood unambiguously by the author and the reader.

The structured representation is just that - a structure representing the
medication order activities, timing etc.

If they don't say the same thing it could mean:

*   the software that created the structural representation has an
error, and creates structures different from the clinical intention
*   the software that created the narrative has an error, and created a
different text from that required by the clinician

As for any other data in the record, there is no 100% guarantee that any of
it is right. The correct comparison is not just between the two, but between
both of them and the original clinical intention, which is the reference.
This comparison will only be made during testing, where the purpose is to
ensure the software is bug-free.

In routine use, inconsistencies probably won't be detected - the doctor will
just assume the software works properly. So it's just a question of making
sure the software works properly...

- thomas


On 29/10/2013 10:07, Diego Bosc? wrote:

And if an inconsistency is detected, which one is supposed to be right?

 

2013/10/29 Thomas Beale 


Just to re-iterate, the 'narrative' property is meant to carry the piece of
text that would appear on a medication or with a medication as supplied by a
pharmacy (including in a hospital). When the administering agent is a human
- the patient, family member or a nurse - this is normally the concrete
direction that is followed. 

The computable form of the order / instruction says the same thing, but in a
computable form, allowing structured querying, analysis, all the usual
stuff.

This is probably the only place where there is content duplication in
openEHR, and as far as I can see, it needs to be like that, since there is
no standard way to generate the narrative text in its correct form from the
computable form (i.e. the Activities etc) - particularly since the text form
can contain quite particular words, 'codes' (like '3td po') and so on. 

If a 'standard' algorithm could be developed for this purpose it would
obviate the need for the narrative property, but I suspect this is a long
way off due to the medically & culturally specific content typical in the
narrative today.

- thomas 

 

 

  _  

Mae?r wybodaeth a gynhwysir yn y neges e-bost hon ac yn unrhyw atodiadau?n
gyfrinachol. Os ydych yn ei derbyn ar gam, rhowch wybod i?r anfonwr a?i
dileu?n ddi-oed. Ni fwriedir i ddatgelu i unrhyw un heblaw am y derbynnydd,
boed yn anfwriadol neu fel arall, hepgor cyfrinachedd. Efallai bydd
Gwasanaeth Gwybodeg GIG Cymru (NWIS) yn monitro ac yn cofnodi pob neges
e-bost rhag firysau a defnydd amhriodol. Mae?n bosibl y bydd y neges 

FW: SV: ACTIVITY and timing

[Heath Frankel]

We use the HL7 V2 TQ data type representation since it has been used in 
healthcare systems for 30 years and supports many of the weird and familiar 
timing scenarios such as BID etc.

Regards

 

Heath


On 13/08/2013, at 8:34 PM, Thomas Beale  
wrote:


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

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

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

However, the danger is that timing information provided elsewhere is not 
standardised. The timing archetype in CKM is as follows:

There is a parseable expression as the last item.

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

*   the range of requirements of clinical modellers (we know many basic 
needs, but I am sure in recent years, more exotic timing requirements have been 
discovered)
*   which of those could be formally expressed, which can't - and in what 
formalism
*   if there is no formal expression that handles all requirements, is it 
ok to use one for (we assume) 80% of cases that are in fact formalisable?
*   how can timing that is formalised in some ugly unreadable syntax be 
archetyped by clinical modellers who quite rightly wouldn't touch such a 
syntax? I.e. how do we make it look like the above archetype, but computer 
processable all the same?
*   if there is a formal expression, what will software do with it? 
Possibilities:

*   display it (i.e. app - back-end interoperability)
*   share it with other systems (i.e. system-system interoperability)
*   actually process it in some way, e.g. generate notifications to 
someone, e.g. nurse, patient?


The problem is, I think solving the timing problem definitively might never 
happen, since there always seems to be some weird new need around the corner, 
and the possible uses of the information in the hospital are likely to be quite 
different from community / GP-based healthcare.

I think that the 'basic' part of any timing than can easily be formalised in 
GTS, iCal, cron (I hadn't thought of cron before, but as an old unix guy, it's 
not a bad one actually) should be formalised, and should be put in the 
ACTIVITY.timing field. I also think that any extra information should be in a 
known location. Do we need an 'other_timing_details: CLUSTER' field in ACTIVITY?

We need some input from clinical professionals and archetype modellers here to 
get further.

Whatever the final solution might be, we should put up a guidance page on the 
wiki now, so I created a new page for this here 
 . 
Please feel free to work on this page rather than just in the mailing lists.

- thomas


On 11/08/2013 07:54, Bj?rn N?ss wrote:

Hi Pablo 

Thanks for the quick response!

 

I guess you are right regarding Cron and ISO 8601 when it comes to implement 
the DV_PARSABLE attribute timing on the ACTIVITY class. 

 

The openEHR-EHR-CLUSTER.timing.v1 is developed to define ?structured 
information about the timing (intended or actual) of administration or use of a 
medicine, other therapeutic good or other intervention that is given on a 
scheduled basis.? And it?s intended use is  ?with medication orders and other 
instructions where timing is complex and needs to be computable.? This 
archetype does also include a parsable element named ?parsable syntax?. 

 

So the key question is: To be able to exchange structured information about 
timing ? would it be better to use openEHR-EHR-CLUSTER.timing.v1 or should we 
use the mandatory parsable timing attribute on ACTIVITY class? 

 

I can see pros and cons: 

 

Use the attribute on ACTIVITY class: 

? To use an attribute that is always present (in EHR Information 
Model). 

? To reduce clinical modeling effort ? since you don?t have to include 
structure about timing in every ACTIVITY.
(I guess clinical modelin

Regarding the use of the Demographics Package...

[Heath Frankel]

Should we consider user_identity archetype into ckm so you can reuse?
Heath
On Jul 3, 2013 8:10 PM, "Athanasios Anastasiou" <
athanasios.anastasiou at plymouth.ac.uk> wrote:

> Hello Heath & Sam
>
> Thank you very much for the helpful replies, it was good to see i am
> somewhat on the right track too.
>
> All the best
> Athanasios Anastasiou
>
>
>
>
> On 02/07/2013 00:43, Heath Frankel wrote:
>
>> Hi Athanasios,
>> As Sam said, the Ocean Multiprac application suite (www.multiprac.com
>> <http://www.multiprac.com>) does this. I have a
>> PERSON.person-individual_**provider that has a ROLE.user as well as a
>> ROLE.healthcare_provider, so your user who is a provider has both user
>> roles and healthcare roles.
>> Similarly I have a PARTY_IDENTITY.user_identity that has the username.
>> I store the credentials in a separate enterprise directory service such
>> as active directory.
>> So to login to our system you need to be authenticated in active
>> directory and have a person in the demographics with the matching
>> user_identity.
>> Our consumer portal works in the same manner.
>> Heath
>>
>> On Jul 1, 2013 8:59 PM, "Athanasios Anastasiou"
>> > plymouth.ac.uk>
>> <mailto:athanasios.anastasiou@**plymouth.ac.uk> plymouth.ac.uk>>>
>> wrote:
>>
>> 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.__open**ehr.org <http://openehr.org>
>> <mailto:openEHR-technical@**lists.openehr.org> lists.openehr.org>
>> >
>> http://lists.openehr.org/__**mailman/listinfo/openehr-__**
>> technical_lists.openehr.org<http://lists.openehr.org/__mailman/listinfo/openehr-__technical_lists.openehr.org>
>> <http://lists.openehr.org/**mailman/listinfo/openehr-**
>> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-te

Regarding the use of the Demographics Package...

[Heath Frankel]

Hi Athanasios,
As Sam said, the Ocean Multiprac application suite (www.multiprac.com) does
this. I have a PERSON.person-individual_provider that has a ROLE.user as
well as a ROLE.healthcare_provider, so your user who is a provider has both
user roles and healthcare roles.
Similarly I have a PARTY_IDENTITY.user_identity that has the username.
I store the credentials in a separate enterprise directory service such as
active directory.
So to login to our system you need to be authenticated in active directory
and have a person in the demographics with the matching user_identity.
Our consumer portal works in the same manner.
Heath
On Jul 1, 2013 8:59 PM, "Athanasios Anastasiou" <
athanasios.anastasiou at plymouth.ac.uk> wrote:

> 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 lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Mimetype ADL

[Heath Frankel]

Hi Thomas,
The value of more specific mime types is that application using the file
can determine how to handle the file such as launching an associated
application to view it.
XML is just text/plain but it is recommended to be application/xml.
I suggest we look into the process of registering a mime type with IANA,
such as application/adl.
Heath
On Apr 17, 2013 6:40 PM, "Thomas Beale" 
wrote:

> On 16/04/2013 07:14, Bert Verhees wrote:
>
>> Hi,
>>
>> Is there a mimetype defined for ADL-files?
>>
>
> There's no dedicated one; a text type should do, but remember ADL is
> UTF-8. I haven't looked up the rules on that but if text/plain allows
> UTF-8, then I would use that.
>
> - thomas
>
>
> __**_
> openEHR-technical mailing list
> openEHR-technical at lists.**openehr.org lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Questions about commit and AUDIT_DETAILS

[Heath Frankel]

Hi Erik,
I agree and I intended to say in my other response that I think this level
of audit trail could be left to individual systems just like you use
http-server log and I use an IHE ATNA implementation. Although it may be
desirable to standardise the data model of the logs I see no reason to
reinvent this in openEHR other than defining some event IDs and profiling
the required data and it'd format for common events such as contributions,
extracts and queries.
Heath
On Jan 30, 2013 7:05 PM, "Erik Sundvall"  wrote:

> Ooops, accidentally sent unfinished mail... see additions below.
>
> On Wed, Jan 30, 2013 at 9:07 AM, Erik Sundvall wrote:
>
>> Hi!
>>
>> On Tue, Jan 29, 2013 at 9:48 PM, Thomas Beale <
>> thomas.beale at oceaninformatics.com> wrote:
>>>
>>>  The point isn't for the server to know what is committed to itself, but
>>> for other systems to know where data that they are sent copies of, was
>>> originally committed.
>>>
>>
>> That was my understanding too. I think of the system id as an identifying
>> logical "domain" for versioning where there is a guarantee that the same
>> version_tree_id (e.g. 3 in 1298745::my.system::3) will never be reused for
>> another commit. In such a domain there should be some mechanism to get the
>> latest version and to assign new non-conflicting version_tree_id's committs
>> in the domain thus has to be synchronized one way or another so that
>> additional writes with same ID get detected and stopped.
>>
>> If those conditions are fulfilled it matters less if things are done on
>> client or server side, but I would guess that it in many cased will be far
>> easer to implement on the server side than to have a distributed sync for
>> clients.
>>
>>
>>> Maybe we need to contemplate capturing both the user device network id
>>> and the server id.
>>
>>
>> In the LiU EEE implementation of the REST architecture described in my
>> thesis (http://www.imt.liu.se/~erisu/2013/phd/) we use the normal
>> http-server log to record user agent (device and browser/agent) and
>> originating IP. The URIs and HTTP redirections are designed in a way that
>> makes it easy to identify the HTTP-log entry associated with a certain
>> commit, so if you have a VERSION of an object and have access to the
>> HTTP-logs you can easily track this for system audit purposes. Since the
>> dates are included in the audit_details of every openEHR VERSION it is also
>> easy to figure out which log file to look in if you happen to have an
>> ordinary log rotation and archiving system.
>>
>> I am not sure that it would always be a too good idea to cram user-agent,
>> IP etc into the CONTRIBUTION or audit_details that are persisted in the EHR
>> and SOMETIMES transferred in EHR extracts. 1) Those details may give away
>> unwanted or unneccearily detailed info to other organisations that you are
>> sharing EHR extracts with. 2)
>>
>
> Here is a more complete version of the last part:
>
> I am not sure that it would always be a too good idea to cram user-agent,
> IP etc into the CONTRIBUTION or audit_details that are persisted in the EHR
> and SOMETIMES transferred in EHR extracts:
>
> 1) Those details may give away unwanted or unnecessarily detailed info to
> other organisations that you are sharing EHR extracts with (for example
> hints about your internal ip network structure, operating systems and
> hardware devices)
>
> 2) If we would be sharing detailed log data outside originating systems,
> then we would need to agree on format and what to record. That could be
> _very_ different for different systems.
>
> I don't say providing slots for such things in the RM would be terribly
> bad, I just want to say that we should think twice and first have good use
> case descriptions pointing out why existing mechanisms (including possible
> uses of feeder_audit) combined with other system logs would not be
> sufficient.
>
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-28673
>
>>
>>
>
> ___
> 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: 

Questions about commit and AUDIT_DETAILS

[Heath Frankel]

I believe that the client application/machine should be recorded in a
separate level audit log, something like the ihe atna.
The contribution audit is intended to support thr versioning control in a
distributed environment of eHR systems do when compositions are exchanged
between systems we know were it was originally committed.
There are many auditable event that occur in an eHR system that are not
supported by thr contribution audit such as reads which require a separate
audit log anyway, this is more at the service layer than in the EHR.
Heath
On Jan 30, 2013 7:18 AM, "Thomas Beale" 
wrote:

>  On 23/01/2013 15:59, pablo pazos wrote:
>
>  Hi Bert / Sam,
>
>  Thanks for your answers.
>
>  The idea is that the new COMPOSITION will be available to the EHR SYSTEM
> when it arrives to the SERVER. I understand the difference between
> finishing a COMPOSITION (e.g. signing and setting the end time) and
> committing it to be available to the system (e.g. other CLIENTs could
> access the new COMPOSITION).
>
> I agree with Bert that AUDIT_DETAILS.system_id should be "the system on
> which the author is working/committing, normally not the server.", but IMO
> this is the opposite to the current definition of that field.
>
>  Moreover, if that field is set to the SERVER's ID it will be redundant,
> because the SERVER knows that the COMPOSITION was committed to itself, but
> what doesn't knows is the ID of the system where the COMSPOTION was
> authored (e.g. the SERVER could identify the CLIENT by it's IP, but 1. IP's
> change, 2. there could be a middleware so the IP received by the SERVER
> could not be the IP of the CLIENT).
>
>  What do you think?
>
>
> The point isn't for the server to know what is committed to itself, but
> for other systems to know where data that they are sent copies of, was
> originally committed. If this information is not available, then that data,
> when sent to another place doesn't indicate where it was committed. If the
> audit trail includes some machine name of a client device, it's no help on
> its own. Maybe we need to contemplate capturing both the user device
> network id and the server id.
>
> It depends on what we think these ids are needed for. The server id is
> easy - when informatoin is shared, you want to know where it was originally
> committed (which might not be the same as the machine or service you got it
> from today) so that further requests could be made there. The utility of
> the client device id is probably only inside the original environment, but
> I am not sure how it would be used. I would be interested in Pablo & Bert's
> ideas...
>
> - 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: 

Questions about the XSD-files.

[Heath Frankel]

Bert,
I too was sharing my knowledge, as one of the authors of the schema whether
they are classed as good or bad, I thought it was worth the effort
explaining the design rationale.
I apologise for wasting your time and will choose more wisely in future
where I spend mine.
Heath
On Nov 28, 2012 5:52 PM, "Bert Verhees"  wrote:

>  On 11/28/2012 02:35 AM, Heath Frankel wrote:
>
> Seref,
> The items element is provided in the structure.xsd for this very reason
> but Bert seems to object to it because of its name or its type or some
> other reason that I have not yet determined.
>
>
> I give up, I don't know what is happening over there, but it takes for me
> too much time. I build my own XSD and forget the one OpenEHR offers.
> (in fact, I have them ready, I just wanted to discuss my knowledge in the
> OpenEHR community, and see if we can work together)
>
> Best regards
> Bert Verhees
>
>  Heath
> On Nov 28, 2012 7:42 AM, "Seref Arikan" 
> wrote:
>
>> I'll attempt to comment on Bert's problem, hoping I understand it :)
>> When you do not have a root element definition in an XSD, you can't
>> create XML documents which will be valid according to that XSD. What Bert
>> is saying is, if we had a bunch of root elements in the XSDs, it would
>> allow us create valid XML with these root elements. At the moment, if you
>> create an XML element with a DVQuantity subclass as the root, it would not
>> be valid according to XSD, because the XSD does not explicitly list
>> DvQuantity as a root element
>>
>> As it is, the XSDs define larger units of documents, and having finer
>> granularity requires having more root elements defined as options in the
>> XSDs.
>>
>> Bert, did I get it?
>>
>>
>>
>>  On Tue, Nov 27, 2012 at 7:24 PM, Heath Frankel <
>> heath.frankel at oceaninformatics.com> wrote:
>>
>>> Bert,
>>> The rule you reference says nothing about concrete types. As far as I am
>>> concerned the items element is satisfying this rule.
>>> You are welcome to change the schema in your system as you see fit just
>>> as linkEHR have done, but I suggest any additional element declarations are
>>> done in a different namespace otherwise you will be producing incompatible
>>> instances.
>>>
>>> I am still not understanding you issues with this element other than
>>> styling. If you have any technical issue please raise a jira issue.
>>>
>>> Heath
>>>   On Nov 27, 2012 8:50 PM, "Bert Verhees"  wrote:
>>>
>>>> Op 27-11-2012 9:07, Heath Frankel schreef:
>>>>
>>>>>
>>>>> Bert,
>>>>> You can define elements to be type of an abstract type allowing any
>>>>> concrete subtype in an instance. This is the intent of the items element,
>>>>> to allow any rotatable concrete type to be represented in a document with
>>>>> root element of items.
>>>>> Heath
>>>>>
>>>>>
>>>> Hi Heath,
>>>>
>>>> You can just have one globally element from Locatable in the XSD, and
>>>> say that XML-instances must comply to that. (just joking)
>>>> 
>>>> There is no other globally defined element in the structures.xsd, so
>>>> there is no other root-element.
>>>>
>>>> Every valid XML-instance has one (only one) root-element. So, many
>>>> schema-processors need at least one root-element in the XSD for
>>>> validation-purpose, and the XML instance must conform to that. Many
>>>> schema-processors can only access root-elements directly. I think that for
>>>> usability and portability the structures.xsd should have that also.
>>>>
>>>> I think this is a left-over situation because (I am looking quite some
>>>> years at OpenEHR), in the past, it was not done to archetype
>>>> ITEM_STRUCTURE's as root, they did only appear as property. I don't know
>>>> when the first ITEM_STRUCTURE derived archetypes appeared in CKM.
>>>>
>>>> I remember Sam mentioning, some years ago, that he didn't like the
>>>> demographics-classes, but that they should be replaced by generic
>>>> structures derived from ITEM_STRUCTURE. I had this discussion with him in
>>>> the context of the Ocean-archetype editor which is build (maybe partly) by
>>>> Sam, and also does not support demographics (It is sometime ago I looked
>>>> for the last time)
>>>>

Questions about the XSD-files.

[Heath Frankel]

True, but you can declare elements in an xsd as an abstract type allowing
any concrete type to be provided in an xml document where the concrete type
is specified using the xs:type attribute. For example:
...

Heath
On Nov 28, 2012 9:07 AM, "Bert Verhees"  wrote:

>
>
> Verstuurd vanaf mijn iPad
>
> Op 27 nov. 2012 om 20:24 heeft Heath Frankel <
> heath.frankel at oceaninformatics.com> het volgende geschreven:
>
> Bert,
> The rule you reference says nothing about concrete types. As far as I am
> concerned the items element is satisfying this rule.
>
> Hi Heath, only concrete classes can be instantiated in XML.
>
> Bert
>
>
> You are welcome to change the schema in your system as you see fit just as
> linkEHR have done, but I suggest any additional element declarations are
> done in a different namespace otherwise you will be producing incompatible
> instances.
>
> I am still not understanding you issues with this element other than
> styling. If you have any technical issue please raise a jira issue.
>
> Heath
> On Nov 27, 2012 8:50 PM, "Bert Verhees"  wrote:
>
>> Op 27-11-2012 9:07, Heath Frankel schreef:
>>
>>>
>>> Bert,
>>> You can define elements to be type of an abstract type allowing any
>>> concrete subtype in an instance. This is the intent of the items element,
>>> to allow any rotatable concrete type to be represented in a document with
>>> root element of items.
>>> Heath
>>>
>>>
>> Hi Heath,
>>
>> You can just have one globally element from Locatable in the XSD, and say
>> that XML-instances must comply to that. (just joking)
>> 
>> There is no other globally defined element in the structures.xsd, so
>> there is no other root-element.
>>
>> Every valid XML-instance has one (only one) root-element. So, many
>> schema-processors need at least one root-element in the XSD for
>> validation-purpose, and the XML instance must conform to that. Many
>> schema-processors can only access root-elements directly. I think that for
>> usability and portability the structures.xsd should have that also.
>>
>> I think this is a left-over situation because (I am looking quite some
>> years at OpenEHR), in the past, it was not done to archetype
>> ITEM_STRUCTURE's as root, they did only appear as property. I don't know
>> when the first ITEM_STRUCTURE derived archetypes appeared in CKM.
>>
>> I remember Sam mentioning, some years ago, that he didn't like the
>> demographics-classes, but that they should be replaced by generic
>> structures derived from ITEM_STRUCTURE. I had this discussion with him in
>> the context of the Ocean-archetype editor which is build (maybe partly) by
>> Sam, and also does not support demographics (It is sometime ago I looked
>> for the last time)
>>
>> It is a valid opinion, but this advice was not followed by the community.
>> However, the demographic-specs are valid inside the OpenEHR specs. They
>> also appear in CKM.
>>
>> But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for
>> other purposes than demographics.
>> There can be XML-instances from ITEM_STRUCTURE-derived.
>> So also for this reason, the XSD should declare ITEM_STRUCTURE derived
>> elements globally.
>>
>>
>> And also besides this all, the globaly defined "items", must be meant to
>> be a property of other definitions, because there is no class in the
>> reference model which is called "items".
>> Considering that, I think, the  "items" is (originally ) meant of type
>> LOCATABLE to satisfy all possible appearances of the property items in
>> structures, which have a semantically other meaning. But this is not
>> following the granularity of the specs. So the "items" properties which are
>> in the structures have a more fine-grained definition. Maybe this is
>> corrected, anyway, this how it should be.
>> So I think, the "items" element it is a left over, an element should be
>> declared globally if it is used in more then one complex type, but it isn't
>> used at all. So it is there doing nothing.
>>
>> That is why I asked about that.
>> -
>> Besides the portability among schema-processors
>>
>> As you can see it in the demographics.xsd which comes from LinkEHR, there
>> is for every concrete class a global element declaration.
>> It has a very precise interface, which makes it easier to develop code
>> against it. That is why it is like that. LinkEHR uses it in code. So, this
>> i

Questions about the XSD-files.

[Heath Frankel]

Seref,
The items element is provided in the structure.xsd for this very reason but
Bert seems to object to it because of its name or its type or some other
reason that I have not yet determined.

Heath
On Nov 28, 2012 7:42 AM, "Seref Arikan" 
wrote:

> I'll attempt to comment on Bert's problem, hoping I understand it :)
> When you do not have a root element definition in an XSD, you can't create
> XML documents which will be valid according to that XSD. What Bert is
> saying is, if we had a bunch of root elements in the XSDs, it would allow
> us create valid XML with these root elements. At the moment, if you create
> an XML element with a DVQuantity subclass as the root, it would not be
> valid according to XSD, because the XSD does not explicitly list DvQuantity
> as a root element
>
> As it is, the XSDs define larger units of documents, and having finer
> granularity requires having more root elements defined as options in the
> XSDs.
>
> Bert, did I get it?
>
>
>
> On Tue, Nov 27, 2012 at 7:24 PM, Heath Frankel <
> heath.frankel at oceaninformatics.com> wrote:
>
>> Bert,
>> The rule you reference says nothing about concrete types. As far as I am
>> concerned the items element is satisfying this rule.
>> You are welcome to change the schema in your system as you see fit just
>> as linkEHR have done, but I suggest any additional element declarations are
>> done in a different namespace otherwise you will be producing incompatible
>> instances.
>>
>> I am still not understanding you issues with this element other than
>> styling. If you have any technical issue please raise a jira issue.
>>
>> Heath
>> On Nov 27, 2012 8:50 PM, "Bert Verhees"  wrote:
>>
>>> Op 27-11-2012 9:07, Heath Frankel schreef:
>>>
>>>>
>>>> Bert,
>>>> You can define elements to be type of an abstract type allowing any
>>>> concrete subtype in an instance. This is the intent of the items element,
>>>> to allow any rotatable concrete type to be represented in a document with
>>>> root element of items.
>>>> Heath
>>>>
>>>>
>>> Hi Heath,
>>>
>>> You can just have one globally element from Locatable in the XSD, and
>>> say that XML-instances must comply to that. (just joking)
>>> 
>>> There is no other globally defined element in the structures.xsd, so
>>> there is no other root-element.
>>>
>>> Every valid XML-instance has one (only one) root-element. So, many
>>> schema-processors need at least one root-element in the XSD for
>>> validation-purpose, and the XML instance must conform to that. Many
>>> schema-processors can only access root-elements directly. I think that for
>>> usability and portability the structures.xsd should have that also.
>>>
>>> I think this is a left-over situation because (I am looking quite some
>>> years at OpenEHR), in the past, it was not done to archetype
>>> ITEM_STRUCTURE's as root, they did only appear as property. I don't know
>>> when the first ITEM_STRUCTURE derived archetypes appeared in CKM.
>>>
>>> I remember Sam mentioning, some years ago, that he didn't like the
>>> demographics-classes, but that they should be replaced by generic
>>> structures derived from ITEM_STRUCTURE. I had this discussion with him in
>>> the context of the Ocean-archetype editor which is build (maybe partly) by
>>> Sam, and also does not support demographics (It is sometime ago I looked
>>> for the last time)
>>>
>>> It is a valid opinion, but this advice was not followed by the community.
>>> However, the demographic-specs are valid inside the OpenEHR specs. They
>>> also appear in CKM.
>>>
>>> But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for
>>> other purposes than demographics.
>>> There can be XML-instances from ITEM_STRUCTURE-derived.
>>> So also for this reason, the XSD should declare ITEM_STRUCTURE derived
>>> elements globally.
>>>
>>>
>>> And also besides this all, the globaly defined "items", must be meant to
>>> be a property of other definitions, because there is no class in the
>>> reference model which is called "items".
>>> Considering that, I think, the  "items" is (originally ) meant of type
>>> LOCATABLE to satisfy all possible appearances of the property items in
>>> structures, which have a semantically other meaning. But this is not
>>> 

Questions about the XSD-files.

[Heath Frankel]

CLUSTER for one. The XML ITS of the RM is not a pure representation of the
RM. Design decisions needed to be made, this is one of them. If you have a
problem with it raise a jira issue.
Heath
On Nov 28, 2012 5:55 AM, "Bert Verhees"  wrote:

>
>
> Verstuurd vanaf mijn iPad
>
> Op 27 nov. 2012 om 20:13 heeft Heath Frankel <
> heath.frankel at oceaninformatics.com> het volgende geschreven:
>
> Bert,
> Items is not a class, it is an attribute.
>
>
> exactly my idea, it is not an attribute in XSD context, but in class
> context.
>
> from which class is it an attribute?
>
> Bert
>
> Heath
> On Nov 27, 2012 8:50 PM, "Bert Verhees"  wrote:
>
>> Op 27-11-2012 9:07, Heath Frankel schreef:
>>
>>>
>>> Bert,
>>> You can define elements to be type of an abstract type allowing any
>>> concrete subtype in an instance. This is the intent of the items element,
>>> to allow any rotatable concrete type to be represented in a document with
>>> root element of items.
>>> Heath
>>>
>>>
>> Hi Heath,
>>
>> You can just have one globally element from Locatable in the XSD, and say
>> that XML-instances must comply to that. (just joking)
>> 
>> There is no other globally defined element in the structures.xsd, so
>> there is no other root-element.
>>
>> Every valid XML-instance has one (only one) root-element. So, many
>> schema-processors need at least one root-element in the XSD for
>> validation-purpose, and the XML instance must conform to that. Many
>> schema-processors can only access root-elements directly. I think that for
>> usability and portability the structures.xsd should have that also.
>>
>> I think this is a left-over situation because (I am looking quite some
>> years at OpenEHR), in the past, it was not done to archetype
>> ITEM_STRUCTURE's as root, they did only appear as property. I don't know
>> when the first ITEM_STRUCTURE derived archetypes appeared in CKM.
>>
>> I remember Sam mentioning, some years ago, that he didn't like the
>> demographics-classes, but that they should be replaced by generic
>> structures derived from ITEM_STRUCTURE. I had this discussion with him in
>> the context of the Ocean-archetype editor which is build (maybe partly) by
>> Sam, and also does not support demographics (It is sometime ago I looked
>> for the last time)
>>
>> It is a valid opinion, but this advice was not followed by the community.
>> However, the demographic-specs are valid inside the OpenEHR specs. They
>> also appear in CKM.
>>
>> But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for
>> other purposes than demographics.
>> There can be XML-instances from ITEM_STRUCTURE-derived.
>> So also for this reason, the XSD should declare ITEM_STRUCTURE derived
>> elements globally.
>>
>>
>> And also besides this all, the globaly defined "items", must be meant to
>> be a property of other definitions, because there is no class in the
>> reference model which is called "items".
>> Considering that, I think, the  "items" is (originally ) meant of type
>> LOCATABLE to satisfy all possible appearances of the property items in
>> structures, which have a semantically other meaning. But this is not
>> following the granularity of the specs. So the "items" properties which are
>> in the structures have a more fine-grained definition. Maybe this is
>> corrected, anyway, this how it should be.
>> So I think, the "items" element it is a left over, an element should be
>> declared globally if it is used in more then one complex type, but it isn't
>> used at all. So it is there doing nothing.
>>
>> That is why I asked about that.
>> -
>> Besides the portability among schema-processors
>>
>> As you can see it in the demographics.xsd which comes from LinkEHR, there
>> is for every concrete class a global element declaration.
>> It has a very precise interface, which makes it easier to develop code
>> against it. That is why it is like that. LinkEHR uses it in code. So, this
>> is the usability-argument.
>>
>> See also this tutorial http://www.herongyang.com/XML-**
>> Schema/Language-Basic-Declare-**Root-Element.html<http://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html>
>> by Dr. Herong Yang:
>>
>> Rule 1. A schema must have at least one Element Declaration Component to
>> declare a root element for the c

Questions about the XSD-files.

[Heath Frankel]

Bert,
The rule you reference says nothing about concrete types. As far as I am
concerned the items element is satisfying this rule.
You are welcome to change the schema in your system as you see fit just as
linkEHR have done, but I suggest any additional element declarations are
done in a different namespace otherwise you will be producing incompatible
instances.

I am still not understanding you issues with this element other than
styling. If you have any technical issue please raise a jira issue.

Heath
On Nov 27, 2012 8:50 PM, "Bert Verhees"  wrote:

> Op 27-11-2012 9:07, Heath Frankel schreef:
>
>>
>> Bert,
>> You can define elements to be type of an abstract type allowing any
>> concrete subtype in an instance. This is the intent of the items element,
>> to allow any rotatable concrete type to be represented in a document with
>> root element of items.
>> Heath
>>
>>
> Hi Heath,
>
> You can just have one globally element from Locatable in the XSD, and say
> that XML-instances must comply to that. (just joking)
> 
> There is no other globally defined element in the structures.xsd, so there
> is no other root-element.
>
> Every valid XML-instance has one (only one) root-element. So, many
> schema-processors need at least one root-element in the XSD for
> validation-purpose, and the XML instance must conform to that. Many
> schema-processors can only access root-elements directly. I think that for
> usability and portability the structures.xsd should have that also.
>
> I think this is a left-over situation because (I am looking quite some
> years at OpenEHR), in the past, it was not done to archetype
> ITEM_STRUCTURE's as root, they did only appear as property. I don't know
> when the first ITEM_STRUCTURE derived archetypes appeared in CKM.
>
> I remember Sam mentioning, some years ago, that he didn't like the
> demographics-classes, but that they should be replaced by generic
> structures derived from ITEM_STRUCTURE. I had this discussion with him in
> the context of the Ocean-archetype editor which is build (maybe partly) by
> Sam, and also does not support demographics (It is sometime ago I looked
> for the last time)
>
> It is a valid opinion, but this advice was not followed by the community.
> However, the demographic-specs are valid inside the OpenEHR specs. They
> also appear in CKM.
>
> But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other
> purposes than demographics.
> There can be XML-instances from ITEM_STRUCTURE-derived.
> So also for this reason, the XSD should declare ITEM_STRUCTURE derived
> elements globally.
>
>
> And also besides this all, the globaly defined "items", must be meant to
> be a property of other definitions, because there is no class in the
> reference model which is called "items".
> Considering that, I think, the  "items" is (originally ) meant of type
> LOCATABLE to satisfy all possible appearances of the property items in
> structures, which have a semantically other meaning. But this is not
> following the granularity of the specs. So the "items" properties which are
> in the structures have a more fine-grained definition. Maybe this is
> corrected, anyway, this how it should be.
> So I think, the "items" element it is a left over, an element should be
> declared globally if it is used in more then one complex type, but it isn't
> used at all. So it is there doing nothing.
>
> That is why I asked about that.
> -
> Besides the portability among schema-processors
>
> As you can see it in the demographics.xsd which comes from LinkEHR, there
> is for every concrete class a global element declaration.
> It has a very precise interface, which makes it easier to develop code
> against it. That is why it is like that. LinkEHR uses it in code. So, this
> is the usability-argument.
>
> See also this tutorial http://www.herongyang.com/XML-**
> Schema/Language-Basic-Declare-**Root-Element.html<http://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html>
> by Dr. Herong Yang:
>
> Rule 1. A schema must have at least one Element Declaration Component to
> declare a root element for the conforming XML document.
>
> That is how it should be, also in my opinion, as I said, for portability
> to all kind of schema-processing environments. I would like to see the
> OpenEHR-foundation to take this position too.
>
> And if they don't, which can result also in valid XSD, they should at
> least explain why they don't. There are many styles for
> schema-organization, and one must make his choice and explain why.
>
> ---
>
> But even if th

Questions about the XSD-files.

[Heath Frankel]

Bert,
Items is not a class, it is an attribute.

Heath
On Nov 27, 2012 8:50 PM, "Bert Verhees"  wrote:

> Op 27-11-2012 9:07, Heath Frankel schreef:
>
>>
>> Bert,
>> You can define elements to be type of an abstract type allowing any
>> concrete subtype in an instance. This is the intent of the items element,
>> to allow any rotatable concrete type to be represented in a document with
>> root element of items.
>> Heath
>>
>>
> Hi Heath,
>
> You can just have one globally element from Locatable in the XSD, and say
> that XML-instances must comply to that. (just joking)
> 
> There is no other globally defined element in the structures.xsd, so there
> is no other root-element.
>
> Every valid XML-instance has one (only one) root-element. So, many
> schema-processors need at least one root-element in the XSD for
> validation-purpose, and the XML instance must conform to that. Many
> schema-processors can only access root-elements directly. I think that for
> usability and portability the structures.xsd should have that also.
>
> I think this is a left-over situation because (I am looking quite some
> years at OpenEHR), in the past, it was not done to archetype
> ITEM_STRUCTURE's as root, they did only appear as property. I don't know
> when the first ITEM_STRUCTURE derived archetypes appeared in CKM.
>
> I remember Sam mentioning, some years ago, that he didn't like the
> demographics-classes, but that they should be replaced by generic
> structures derived from ITEM_STRUCTURE. I had this discussion with him in
> the context of the Ocean-archetype editor which is build (maybe partly) by
> Sam, and also does not support demographics (It is sometime ago I looked
> for the last time)
>
> It is a valid opinion, but this advice was not followed by the community.
> However, the demographic-specs are valid inside the OpenEHR specs. They
> also appear in CKM.
>
> But still ITEM_STRUCTURE-derived archetypes appeared in CKM, but for other
> purposes than demographics.
> There can be XML-instances from ITEM_STRUCTURE-derived.
> So also for this reason, the XSD should declare ITEM_STRUCTURE derived
> elements globally.
>
>
> And also besides this all, the globaly defined "items", must be meant to
> be a property of other definitions, because there is no class in the
> reference model which is called "items".
> Considering that, I think, the  "items" is (originally ) meant of type
> LOCATABLE to satisfy all possible appearances of the property items in
> structures, which have a semantically other meaning. But this is not
> following the granularity of the specs. So the "items" properties which are
> in the structures have a more fine-grained definition. Maybe this is
> corrected, anyway, this how it should be.
> So I think, the "items" element it is a left over, an element should be
> declared globally if it is used in more then one complex type, but it isn't
> used at all. So it is there doing nothing.
>
> That is why I asked about that.
> -
> Besides the portability among schema-processors
>
> As you can see it in the demographics.xsd which comes from LinkEHR, there
> is for every concrete class a global element declaration.
> It has a very precise interface, which makes it easier to develop code
> against it. That is why it is like that. LinkEHR uses it in code. So, this
> is the usability-argument.
>
> See also this tutorial http://www.herongyang.com/XML-**
> Schema/Language-Basic-Declare-**Root-Element.html<http://www.herongyang.com/XML-Schema/Language-Basic-Declare-Root-Element.html>
> by Dr. Herong Yang:
>
> Rule 1. A schema must have at least one Element Declaration Component to
> declare a root element for the conforming XML document.
>
> That is how it should be, also in my opinion, as I said, for portability
> to all kind of schema-processing environments. I would like to see the
> OpenEHR-foundation to take this position too.
>
> And if they don't, which can result also in valid XSD, they should at
> least explain why they don't. There are many styles for
> schema-organization, and one must make his choice and explain why.
>
> ---
>
> But even if they don't, I write my own XSD, I can live without the
> OpenEHR-XSD, but it would be nice to have following my purpose defined XSD
> from the foundation.
>
> Thanks for your reply
>
> Bert
>
> __**_
> openEHR-technical mailing list
> openEHR-technical at lists.**openehr.org lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121128/157e5882/attachment.html>

Questions about the XSD-files.

[Heath Frankel]

Bert,
You can define elements to be type of an abstract type allowing any
concrete subtype in an instance. This is the intent of the items element,
to allow any rotatable concrete type to be represented in a document with
root element of items.
Heath
On Nov 27, 2012 6:19 PM, "Bert Verhees"  wrote:

> On 11/27/2012 04:26 AM, Thomas Beale wrote:
>
>> On 26/11/2012 17:02, Bert Verhees 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.
>>>
>>
>> I think it just did ;-)
>>
>> Early in 2013, the specifications will be start being revamped. That will
>> be an opportunity for people to offer & improve changes and updates to
>> existing specifications.
>>
>
> Why didn't the website offer this XSD, for so many years.
> It is especially important because Sam and Seref stress the importance of
> the XSD and that they are maintained in formal way.
> That I never realized.
> Under these circumstances it almost begins to look like a statement, but I
> couldn't imagine what.
>
> So it is just a small question, but it seems hard to answer.
>
> But early 2013 is very near, so I will be patient :)
> I can live with the XSD from Diego, which looks very well made.
>
> Thanks again Diego.
>
> regards
> Bert Verhees
>
>
>
>
>
> __**_
> openEHR-technical mailing list
> openEHR-technical at lists.**openehr.org lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Questions about the XSD-files.

[Heath Frankel]

Hi Bert,
Sorry but I struggled to understand the issue you have below. Would you mind
looking at my comments below and see if I have understood them correctly?

Heath

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Bert Verhees
Sent: Tuesday, 27 November 2012 3:07 AM
To: For openEHR technical discussions
Subject: Questions about the XSD-files.

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.


I commented it out, and it still validates fine.

[HKF: ] What did you comment out, the entire element? 
Although this is not necessary when you have a composition instance, if you
want to serialize an ITEM_STRUCTURE as a root of an XML document perhaps for
a query result or internal application purposes then this gives you a
standard schema element to do this. If you don't use it then commenting out
will not hurt. What is the problem with its existence?

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.
[HKF: ] The element above is used for all these subtypes.

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.
[HKF: ] It was if you used the items element above.

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.
[HKF: ] Are you talking about DATA_VALUE types or everything? Personally I
don't see the value it would add overhead n the in memory schema objects
used for validation.
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.
[HKF: ] Yeah, I guess that shows the EHR focus of the specs. I also have a
schema that could be used, I may have already put it up in Jira.

Thanks
Bert Verhees



___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or
g
-- next part --
An HTML attachment was scrubbed...
URL: 

Understanding how to commit contributions to an EHR Server with XML

[Heath Frankel]

Hi Pablo,

 

You need to understand that some of the RM classes are functional object
rather than data objects and hence are not currently considered
serializable, VERSION_OBJECT, EHR and perhaps CONTRIBUTION are examples of
these. There is no specific statement about this in the specifications, and
it can be reconsidered and clarified as we better understand this, but you
can recognise classes in this category when they use object references
rather than containment. VERSIONED_OBJECT has a counter-part of
X_VERSIONED_OBJECT defined in the EHR EXTRACT specification which is
serializable and has an existing schema located at
http://www.openehr.org/releases/1.0.2/its/XML-schema/Extract.xsd (linked
from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html).   

 

Looking specifically at Contribution, it only has a uid and a list of object
references so it isn't very useful unless you have a use case that wants to
list all the contributions for a particular EHR or similar. There may be the
need for an X_CONTRIBUTION class in future.

 

I _think_ I understand this part, but at the implementation level (and using
REST services as plan to do) means some things should be serialized. 

[HKF: ] I agree there is a need to serialize the contribution, but we need
to understand the true requirements. Do we need a new X_CONTRIBUTION class
that contains VERSION objects or is the existing CONTRIBUTION class with
object references sufficient for use in the context I suggested in the other
email. Collaborative specification and implementation experience will help
answer this.

I know there are a lot of ways of serializing things like Versions contained
in a Contribution, e.g. I can send different params in the HTTPRequest body,
each one being one Version XML (this emulated the Ocean's CommitContribution
service), 

[HKF: ] Not sure what you mean here

 

or I can send only one XML on the body for the whole Contribution, this
second way is what I try to do).

[HKF: ] You indicated otherwise in your previous email

 

 

The kind of thing you are trying to do is more related to the service model
than the Reference Model and as you know there is only vendor specific
specifications in this area. From Thomas' service overview you see there are
two layers a EHR Service and a Virtual EHR Service. Not sure it is quite
understand what distinguishes the two of these but there is some indication
that the Virtual EHR provides aggregation of lower layer services including
the EHR and Demographic services while also providing helper functionality
such as contribution building and query result management. Another key
differentiator is granularity of service calls, the Virtual EHR has fine
grained, more frequent calls while the EHR service has course grained, less
frequent calls.

 

This little project is about a simple EHR Service to commit and retrieve
Compositions in XML format (the granularity level here is the Composition).

I understand a lot of this has to do with the service, but behind that
interface I have to build a persistence layer, so understanding the model is
also important (and I'm not an expert on the change_control package, so this
is a great learning experience for me too).

 

As I mentioned, I don't want (and I can't) build a complete version
controlled EHR server, this is just a little system so my students can play
around with my EHRGen tool (I use it to generate different EMR systems),
committing/retrieveing compositions to/from a shared EHR server.

[HKF: ] Which is why it makes sense to align with an existing implementation
so that you could look at replacing it with a more enterprise scale
implementation in the future.

 

The problem that I have identified in my implementations over the years is
that the use of the openEHR RM classes of AUDIT_DETAILS and VERSION are not
very useful in the commit contribution operation, especially if there is
some work being done on the service side, whether it is at the Virtual EHR
service or EHR Service layer. Attributes such as system_id and
time_committed are obvious candidates to be set by the service not by the
client but the RM state that these are mandatory and my most recent work
provides a service operation message that excludes these from the commit
contribution message type but instead has the other RM attributes necessary
(e.g. change_type and description) for the service itself to build the valid
RM objects to be persisted. This CONTRIBUTION_VERSION class is a potential
candidate to be added to the Extract or Service models to support
contribution operations.

 

I found the same problem: the change_control objects are distributed
objects, so at one moment in time some parts of an object may be on the
server, some other parts on the client and other parts not yet created. This
is very unclear on the specs since it lacks time based diagrams to show what
objects are created at what time and when. This could be a good improvement
to the specs, what do you

Understanding how to commit contributions to an EHR Server with XML

[Heath Frankel]

Hi Pablo,

I think we have an excellent opportunity here to take this offline with Erik
to work up a combined logical service specification and RESTful technical
service specification as a candidate for the openEHR service model.

 

It looks like you?re looking for a Virtual EHR Service. The other one you
may want to look at if you haven?t already is the Marand Think!EHR at
http://openehr.org/wiki/display/spec/Marand+Think%21EHR+service+interface
(although it is under the EHR Service area I consider this more like a
Virtual EHR Service due to its operation granularity). In the interest of
consolidation you should consider using something like this but since Erik
has already implemented a RESTful service you should be looking at something
closer to his API. 

 

See comments below.

 

Heath

 

>From your & Thomas comments, I've designed this little protocol:

 

1.  createContribution: client sends a XML contribution (based on
 EEE-v1.xsd) to the server with references
to Versions that will be added later (Versions are in the client)

[HKF: ] Agree, but you may want to not provide any data in this operation
like in the Think!EHR specification, since you probably don?t know what the
contribution looks like yet, even the commit audit. You can think of this as
creating a placeholder to which you versions. Rather than not return a
response message you may want to return the empty Contribution object with
service side attributes populated such as system_id, contribution uid and a
temporary commit_time, this allows you to reference the contribution in
subsequent calls.

2.  addVersion: adds a Version to a contribution (the XML version is
based on openEHR Version.xsd), the reference to the correspondent
contribution is in Version.contribution. A contribution is committeable when
all referenced versions are added to the server.

[HKF: ] The Think!EHR has operations such as CreateComposition and
ModifyComposition, perhaps these don?t quite align with a RESTful approach
but logically what you are trying to achieve here is some context to apply
preconditions ensuring a composition does or does not already exist. It also
allows you to just provide the composition object and have the version
maintenance done for the caller. Having said that I find that not exposing
the version can be a bit limiting at times in more complicated situations.  

The Think!EHR maintains a session context so there is no need to provide a
reference to the contribution but in a more stateless paradigm you would
need to provide a reference to the contribution, the most obvious place to
do this is using the Version object. 

My more recent thinking regarding the response to these operations is to
return the updated contribution object since it only has references the
versions it contains this is not too verbose.

3.  commitContribution: the client tries to finalize the transaction &
the contribution / versions / compositions are added to a EHR on the server
(shared record).

[HKF: ] This is where the contribution audit details are more likely to be
known, by using the contribution object most recently returned in a previous
operation you can submit the entire contribution object to commit its
contents. Again the finalized contribution would be returned.

 

What do you think of this approach?

 

 

I think I found an issue (or just a confusion of names) on the specs about
object_ids:

 

1.  common_im p. 56 describes VERSION.uid as owner_id,
creating_system_id, version_tree_id, there is also an operation
VERSION.owner_id().
2.  common_im p. 40 says VERSION.owner_id() extracts the uid of the
owning VERSIONED_OBJECT.
3.  common_im p. 46 says the VERSION.uid is object_id,
creating_system_id, version_tree_id.
4.  common_im p. 46 says the object_id part of the VERSION.uid is a
copy of the uid of the container VERSIONED_OBJECT.
5.  common_im p. 53 the owner_id attribute is mentioned on
VERSIONED_OBJECT to be the EHR id.

 

If I understand the idea: VERSION points to VERSIONED_OBJECT and
VERSIONED_OBJECT points to EHR, is that right?

 

[HKF: ] Right

 

What do you think about leaving the name owner_id for the pointer to the EHR
and object_id for the pointer to the VERSIONED_OBJECT?

 

[HKF: ] I think the class specification is not really able to be modified
but the descriptive text could be made more clear. I agree that object_id is
a better term and a term I use a lot. In the case of the VERSIONED_OBJECT
owner_id it needs to be generic because It is used for demographic records
(repositories) as well as health records.


-- 
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: Sun, 7 Oct 2012 21:27:35 +0200
Subject: Re: Understanding how to commit contributions to

Understanding how to commit contributions to an EHR Server with XML

[Heath Frankel]

Hi Erik,

I notice that you have provided a schema for VERSIONED_OBJECT which doesn?t
align with the RM class and overlaps with the X_VERSIONED_OBJECT already
defined in the extract.xsd. I think we should leave VERSIONED_OBJECT as not
serializable and use the X_VERSIONED_OBJECT class as the serializable class
as what I believe is intended by the specifications.

 

I agree we should add the EHR_STATUS and EHR_ACCESS types, there is an
existing issue at SPECPR-26 for this.

 

I like the idea of the extended VERSION_OBJECT classes but this only has
value if this can be done in a way that makes the data element strongly
typed.  

 

Regards

 

Heath

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Erik Sundvall
Sent: Monday, 8 October 2012 5:58 AM
To: For openEHR technical discussions
Subject: Re: Understanding how to commit contributions to an EHR Server with
XML

 

Hi!

 

A CONTRIBUTION points to the IDs of it's contained VERSIONED_OBJECTs and the
VERSIONED_OBJECTs at the same time points to their  related CONTRIBUTION,
thus it is probably easiest to finalize them in the same transaction in most
systems if they are stored/retrieved as  separate objects. (You have
probably already figured that out, I am just trying to avoid
misunderstandings by newcomers that might be reading.) 

 

In the LiU EEE REST based approach we have added a temporary writing space
called "Contribution Builder" where you can add/modify a collection of
VERSIONED_OBJECTs until you are satisfied and then make a call to get them
committed into the EHR in a combined CONTRIBUTION. 

 

Another option is of course to send a collection of VERSIONED_OBJECTs (from
a client) with e.g. a bit of XML-wrapping (also including metadata for the
CONTRIBUTION). We have not finished specifying and testing an XML
serialization for that yet, but that could of course be done (now we use a
Java-based object as collection to pass data from the Contribution Builder).

 

I have now uploaded an old XSD (from some experiments 2010) containing
definition of CONTRIBUTIONs (and some other stuff) as an attachment to
http://www.openehr.org/wiki/display/dev/Persistence - It should be
considered as an experimental non-official pre-alpha version... 

 

(The LiU EEE REST design paper has been submitted for review, see
http://www.openehr.org/wiki/display/projects/Projects+Home Contact me if you
need a personal login to our tiny demo-server.)


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

 

On Sat, Oct 6, 2012 at 5:13 PM, pablo pazos  wrote:

Hi all,

 

I found there is no CONTRIBUTION XSD defined on the openEHR XDS, and if it
exists, I can't commit CONTRIBUTIONs using only one XML message, because
CONTRIBUTION references (using OBJECT_REF) the VERSIONs I need to commit,
but each VERSION also references (by OBJECT_REF) the container CONTRIBUTION.

 

The main problem here is: the instances of those classes (CONTRIBUTION and
VERSION) are distributed objects. So if I send 2 messages to
the EHR Server, one to create the CONTRIBUTION and other to create VERSIONs,
the fisrt CONTRIBUTION.versions will be empty on the server, so invalid for
a while (until it's VERSIONS are committed).

 

So, I'm beginning to suspect that I need a little protocol to be defined
here. The other option is to define my own XSD for an envelope that could
include both, CONTRIBUTION and it's VERSIONs. I prefer to define a protocol
than new custom XSDs.

 

Does anyone that implemented a service like this came to the same
conclusion?

 

All your comments will be of great help, thank you.


-- 
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: pazospa...@hotmail.com
To: openehr-technical at lists.openehr.org
Subject: Understanding how to commit contributions to an EHR Server with XML
Date: Fri, 5 Oct 2012 15:14:15 -0300

 

Hi all,

 

I'm studying the change_control package to create a simple example of data
commit to an EHR Server (to be used in a future course). I'm also reading
the service examples published on the wiki (Ocean & Marand EHR Services).

 

As I understand it, when an EMR app (local) wants to commit data to an EHR
Server (global/shared), all committed data (e.g. a list of
Version) should be referenced by a Contribution. Also, each
Version references the container Contribution. All references
are managed using OBJECT_REF instances.

 

My idea is to make the commits using XML messages (following openEHR XSDs)
with only one message per commit.

I don't know if I can represent both references using openEHR XML
(Contribution->Version & Version->Contribution).

 

I suppose this operation [1] on the Ocean's EHR Services is resolving both
references internally: void CommitContribution(HierObjectId ehrId,
AuditDetails commitAudit, OriginalVe

Understanding how to commit contributions to an EHR Server with XML

[Heath Frankel]

Hi Pablo,

You need to understand that some of the RM classes are functional object
rather than data objects and hence are not currently considered
serializable, VERSION_OBJECT, EHR and perhaps CONTRIBUTION are examples of
these. There is no specific statement about this in the specifications, and
it can be reconsidered and clarified as we better understand this, but you
can recognise classes in this category when they use object references
rather than containment. VERSIONED_OBJECT has a counter-part of
X_VERSIONED_OBJECT defined in the EHR EXTRACT specification which is
serializable and has an existing schema located at
http://www.openehr.org/releases/1.0.2/its/XML-schema/Extract.xsd (linked
from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html).   

 

Looking specifically at Contribution, it only has a uid and a list of object
references so it isn?t very useful unless you have a use case that wants to
list all the contributions for a particular EHR or similar. There may be the
need for an X_CONTRIBUTION class in future.

 

The kind of thing you are trying to do is more related to the service model
than the Reference Model and as you know there is only vendor specific
specifications in this area. From Thomas? service overview you see there are
two layers a EHR Service and a Virtual EHR Service. Not sure it is quite
understand what distinguishes the two of these but there is some indication
that the Virtual EHR provides aggregation of lower layer services including
the EHR and Demographic services while also providing helper functionality
such as contribution building and query result management. Another key
differentiator is granularity of service calls, the Virtual EHR has fine
grained, more frequent calls while the EHR service has course grained, less
frequent calls.

 

The Contribution Builder functionality that Erik references fits into the
Virtual EHR layer while the CommitContribution operation on the Ocean EHR
Service you reference below is at the EHR Service layer. The later expects
something like the former to build the contribution to be submitted as a
complete contribution.

 

The implementation of the Ocean EHR Service operation below leaves the
contribution to be constructed by the EHR Service, however the contribution
UID can be specified in the version(s) being committed along with the audit
details provided in the operation parameters. So as Erik indicates, the
contribution object is finalized in the same transaction as the VERSION
objects but the work to build the contribution object is done by the EHR
Service.

 

Ocean also has a Virtual EHR service which provides contribution builder
functionality, it uses the EHR Service CommitContribution operation to
finalize the contribution to storage.

 

So from this perspective, the additional piece of XSD required is actually
specified in the service specification as an operation message rather than a
RM schema. This can be aligned with the definition of the EHR EXTRACT schema
since they are really extract operation messages and we do need to consider
how this works in a RESTful paradigm so that we can align the message types
used in a SOAP service with a REST service. 

 

The problem that I have identified in my implementations over the years is
that the use of the openEHR RM classes of AUDIT_DETAILS and VERSION are not
very useful in the commit contribution operation, especially if there is
some work being done on the service side, whether it is at the Virtual EHR
service or EHR Service layer. Attributes such as system_id and
time_committed are obvious candidates to be set by the service not by the
client but the RM state that these are mandatory and my most recent work
provides a service operation message that excludes these from the commit
contribution message type but instead has the other RM attributes necessary
(e.g. change_type and description) for the service itself to build the valid
RM objects to be persisted. This CONTRIBUTION_VERSION class is a potential
candidate to be added to the Extract or Service models to support
contribution operations.

 

I feel it is truly a high priority for us to start aligning the various
implementation APIs ASAP before we get too many more candidates, at least a
minimum core set of operations. I think we have enough experience to get
this started, I think the process is close to being finalised so now we just
need contributors.

 

Heath

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of pablo pazos
Sent: Saturday, 6 October 2012 3:44 AM
To: openeh technical
Subject: Understanding how to commit contributions to an EHR Server with XML

 

Hi all,

 

I'm studying the change_control package to create a simple example of data
commit to an EHR Server (to be used in a future course). I'm also reading
the service examples published on the wiki (Ocean & Marand EHR Services).

 

As I understand it, when an EMR app (local) wants to commit data to

Setting Quantity->Unit to "yr" get's stored as "a"

[Heath Frankel]

A is the UCUM standard representation of the year unit. AE supports the
reading of both for backward compatibility but will output the standard.

Heath

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Athanasios Anastasiou
Sent: Friday, 5 October 2012 7:20 PM
To: openeh technical
Subject: Setting Quantity->Unit to "yr" get's stored as "a"

Hello everyone

I think that there must be a small typo with the AE when setting the "yr"
unit of the "Time" property constraint in a DV_QUANTITY.

While all the "Time" units are stored as expected in the XML / ADL output
(e.g. "s","min","h" and others) the "yr" unit is stored as "a" 
(...annum, anni (?)).

The unit is read back from a file as "yr". If i edit the ADL so that "units
= <[some string]>", there is no complaint and [some string] will appear in
the AE.

Could this be a typo or am i missing something here? (Shouldn't it be just
"y"?)

All the best
Athanasios Anastasiou


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

Entities & Relationships within the EHR

[Heath Frankel]

Anthanasios,
What we have Don in research based projects is use a persistent composition
to record the cohort that the subject belongs too. It could be done using
demographics where we have a registration relationship associated with the
party but when you want population query on the ehr data you don't want to
be doing a lookup on demographics to find the members of the cohort. Using
this approach we didn't need to provided a hard link between an particular
composition and the cohort as we were able to use aql t determine cohort
membership and the composition template of interest was enough. But of you
do need a hard link for some reason then as Thomas suggested links would be
one way to do it, which allows a type property on the link. An archetyped
DV_EHR_URI element value is another way that has been used mainly because
it is supported by the archetype editor but I find this a softer link which
is harder to implement queries against because it is not an intrinsic part
of the RM.
Personally I think the locatable_ref class is a more computable structure
since you don't need to parse the URI and account for the variations of
absolute/relative URIs and latest or specific versions, to extract the
object id to retrieve the object to traverse the path. Perhaps a more
restful implementation would work better with URIs. Problem is
locatable_ref is only used in one place in the RM, not sure why this
instruction details link was handled different.
All this is implentation specific and we need to find a logical best
practice, which I think is link since there is no restrictions where it can
be used, but this is also it downside until we understand how to constrain,
validate and query links efficiently.
Heath
On 04/09/2012 8:26 PM, "Athanasios Anastasiou" <
athanasios.anastasiou at plymouth.ac.uk> wrote:

> Hello everyone
>
> I am coming across an openEHR use case for which there seem to be more
> than one ways to deal with and that i would appreciate your help with.
>
> The main question is this:
> When creating COMPOSITIONs that describe Template(able) stand-alone
> entities that are well defined and should have clear relationships with
> each other, is it a good practice to include "ID"s and references in order
> to establish these relationships?
>
> A representative example:
> In a Clinical Trials setting, there exist entities that should have clear
> relationships with each other in order for queries to return properly
> structured data that can later be used in analysis.
>
> For example, a COMPOSITION describing a "Site" should have a harder way of
> linking it to the "Trial" than simple membership to the same EHR Folder
> (The naming of the Folder will become an issue).
>
> All the same, the most interesting COMPOSITION, the one that contains the
> data collected, should have a hard way of referencing [the "Trial", "Site",
> "Stage", "Research Staff performing the data collection"] or other entity.
>
> Some of these relationships are already there (A Trial Group (e.g. Control
> / Condition A, B, C), can possibly be expressed via the entities in the
> Demographics package) and i suppose that it is advisable to use them but
> what about describing new relationships?
>
> Looking forward to hearing from you
> Athanasios Anastasiou.
>
> P.S. Do you think that it would be beneficial to add an
> "OBJECT_RELATIONSHIP" entity to the Content package just like the
> "Party_Relationship" of the Demographics Package? This would completely
> describe relationships between entities (source, target, ordering,
> multiplicity,...). In this way, we could even do away with the "strict"
> tree organisation of the EHR and express the whole storage as a graph of
> Template(able) entities interconnected with (proper)
> "OBJECT_RELATIONSHIP"s. What do you think?
>
> __**_
> openEHR-technical mailing list
> openEHR-technical at lists.**openehr.org lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL: 

What should AQL return in this case?

[Heath Frankel]

Hi Seref, It would return a cross join of the X.attr and Y.attr, but only
from EHRs with both an X and Y.

We have uses workflow ids because this is more efficient to evaluate than
URIs (including links) due to string length and being bidirectional, but
this only works for certain usecases.
Heath.
On 20/08/2012 8:49 PM, "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
>
> [image: 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: 

-- next part --
A non-text attachment was scrubbed...
Name: aql-result-set-question.png
Type: image/png
Size: 35089 bytes
Desc: not available
URL: 

Should not node identifiers in runtime paths be mandatory?

[Heath Frankel]

Hi Thomas,

I actually didn't even consider the fact that DV_QUANTITY didn't have a node
ID property, but good point. My point was that the units property provides
the information required to determine if a speed limit value was mph or
km/h.

 

Not sure I like the idea of adding the property attribute to DV_QUANTITY,
this is metadata that can be derived from the archetype if required but I
just don't see the use case.  I think we have more than enough metadata in
the instance already.

 

Heath

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas
Beale
Sent: Wednesday, 15 August 2012 8:02 PM
To: openehr-technical at lists.openehr.org
Subject: Re: Should not node identifiers in runtime paths be mandatory?

 

On 15/08/2012 01:10, Heath Frankel wrote:

Hi Seref/Thomas,

Node IDs at0022 and at0023 have no semantic significance, they are just a
value of a speed limit element no matter if they are in km/h or mph. These
are just alternative value constraints on the value due to different units
allowed and range when using that unit. When you query you would want to get
all speed limit values and if you needed to compare then you need to convert
based on the units.


Hi Heath,

you are no doubt assuming that the 'QUANTITY' type in the RM doesn't carry
archetype node+id information, which is indeed the case for DV_QUANTITY as
used in openEHR, but I was not assuming that for the example. In that case
you are right of course - querying would have to take account of it in
another way. One thing we potentially should do is include the 'property'
attribute in DV_QUANTITY, for just this purpose. 

I will add something to the documentation to indicate these subtleties.




 

The instance should actually look like the following

 

items = <

["1"] = < -- ELEMENT

archetype_node_id = <"at0004">

value = < --
QUANTITY

units = <"mph">

magnitude = <25>

>

>

["2"] = <>

etc

> 

 

However, one area that is problematic is in the validator, how do we know
which constraint we should use when the constraints are ambiguous. The
example provided previously does no have this issue but if you consider an
element with an alternative values of type DV_TEXT allowing free text and
DV_CODED_TEXT in some specified terminology. 

 

ELEMENT[at0004] matches { 

value matches {

DV_TEXT matches { * }

DV_CODED_TEXT matches { -- km per hour

defining_code matches { |SNOMED-CT::| }

}

}

}

 

This cases doesn't require at-codes because they are different types, but
they are still ambiguous due to the inheritance allowing any coded term to
be used, not just the specified term.

 

Here it would be nice to have an at-code in the instance to differentiate
which alternative is being used.


as it happens, due to another discussion I have already changed this rule to
say force at-codes even if the RM types are different under a single-valued
attribute. This will be annoying for some current archetypes, but that's
life.

- thomas

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

Should not node identifiers in runtime paths be mandatory?

[Heath Frankel]

Hi Seref,

Not sure I understand your point anymore.

 

The quote you have reference seems to indicate that it is part of a greater
explanation of the purpose of node ID. Semantics is one, and as a
distinguisher is another. For me, the speed limit example is the second and
because DV_QUANTITY has a unit property that provides the querying
requirement you are looking for there is no need for the node ID to be
provided in the instance, which as Thomas points out doesn't exist. The free
text/coded text example, which Ian constantly battles with, is one case
where the distinguish does add value to a validator, but again we have
nowhere to put.

 

Heath

 

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Seref
Arikan
Sent: Wednesday, 15 August 2012 6:47 PM
To: For openEHR technical discussions
Subject: Re: Should not node identifiers in runtime paths be mandatory?

 

Hi Heath, 
Maybe semantics is not the right word for it, but it is what would help
me/my code easily express that the interest is in a particular element,
given a bunch of options. The lack of node identifier is thus at least lack
of information, if not semantics. 

Not to suggest that you're wrong in this specific example, but the following
quote from page 47 of the adl 1.5 spec makes one inclined to assign the
responsibility of expressing semantics to node identifiers, or at least that
is my impression:

"The node identifier also performs a semantic function, that of giving a
design-time meaning to the
node, by equating the node identifier to some description"

Maybe I've incorrectly generalized this statement. 

Kind regards
Seref

 

On Wed, Aug 15, 2012 at 1:10 AM, Heath Frankel
 wrote:

Hi Seref/Thomas,

Node IDs at0022 and at0023 have no semantic significance, they are just a
value of a speed limit element no matter if they are in km/h or mph. These
are just alternative value constraints on the value due to different units
allowed and range when using that unit. When you query you would want to get
all speed limit values and if you needed to compare then you need to convert
based on the units.

 

The instance should actually look like the following

 

items = <

["1"] = < -- ELEMENT

archetype_node_id = <"at0004">

value = < --
QUANTITY

units = <"mph">

magnitude = <25>

>

>

["2"] = <>

etc

> 

 

However, one area that is problematic is in the validator, how do we know
which constraint we should use when the constraints are ambiguous. The
example provided previously does no have this issue but if you consider an
element with an alternative values of type DV_TEXT allowing free text and
DV_CODED_TEXT in some specified terminology. 

 

ELEMENT[at0004] matches { 

value matches {

DV_TEXT matches { * }

DV_CODED_TEXT matches { -- km per hour

defining_code matches { |SNOMED-CT::| }

}

}

}

 

This cases doesn't require at-codes because they are different types, but
they are still ambiguous due to the inheritance allowing any coded term to
be used, not just the specified term.

 

Here it would be nice to have an at-code in the instance to differentiate
which alternative is being used.

 

Heath

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas
Beale
Sent: Wednesday, 15 August 2012 2:07 AM


To: openehr-technical at lists.openehr.org
Subject: Re: Should not node identifiers in runtime paths be mandatory?

 

On 14/08/2012 10:34, Seref Arikan wrote:

Greetings, 
According to adl 1.5 document on the openEHR web site (issued 25 Jan 2012),
Section 5.3.6.3, the runtime paths for single valued attributes can omit
node identifer.
The example given in the document uses miles per hour and km per hour
alternatives. The thing is, if the runtime path is what is going to be
persisted (and I can't see any other practical cases), the persisted data
will have no information to mark the semantics of the selection of an option
among alternatives.


actually, this text is a bit misleading. If we have the archetype

ELEMENT[at0004] matches { -- speed limit
value matches {
QUANTITY[at0022] matches { -- miles per hour
magnitude matches {|0..55|}
property matches {"velocity"}
units matches {"mph"}
}
QUANTITY[at0023] matches { -- km per hour
magnitude matches {|0..100|}
property matches {"velocity"}
units matches {"km/h"}
}
}
}

then the data instance created from the at0022 form of the QUANTITY wi

Should not node identifiers in runtime paths be mandatory?

[Heath Frankel]

Hi Seref/Thomas,

Node IDs at0022 and at0023 have no semantic significance, they are just a
value of a speed limit element no matter if they are in km/h or mph. These
are just alternative value constraints on the value due to different units
allowed and range when using that unit. When you query you would want to get
all speed limit values and if you needed to compare then you need to convert
based on the units.

 

The instance should actually look like the following

 

items = <

["1"] = < -- ELEMENT

archetype_node_id = <"at0004">

value = < --
QUANTITY

units = <"mph">

magnitude = <25>

>

>

["2"] = <>

etc

> 

 

However, one area that is problematic is in the validator, how do we know
which constraint we should use when the constraints are ambiguous. The
example provided previously does no have this issue but if you consider an
element with an alternative values of type DV_TEXT allowing free text and
DV_CODED_TEXT in some specified terminology. 

 

ELEMENT[at0004] matches { 

value matches {

DV_TEXT matches { * }

DV_CODED_TEXT matches { -- km per hour

defining_code matches { |SNOMED-CT::| }

}

}

}

 

This cases doesn't require at-codes because they are different types, but
they are still ambiguous due to the inheritance allowing any coded term to
be used, not just the specified term.

 

Here it would be nice to have an at-code in the instance to differentiate
which alternative is being used.

 

Heath

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas
Beale
Sent: Wednesday, 15 August 2012 2:07 AM
To: openehr-technical at lists.openehr.org
Subject: Re: Should not node identifiers in runtime paths be mandatory?

 

On 14/08/2012 10:34, Seref Arikan wrote:

Greetings, 
According to adl 1.5 document on the openEHR web site (issued 25 Jan 2012),
Section 5.3.6.3, the runtime paths for single valued attributes can omit
node identifer.
The example given in the document uses miles per hour and km per hour
alternatives. The thing is, if the runtime path is what is going to be
persisted (and I can't see any other practical cases), the persisted data
will have no information to mark the semantics of the selection of an option
among alternatives.


actually, this text is a bit misleading. If we have the archetype

ELEMENT[at0004] matches { -- speed limit
value matches {
QUANTITY[at0022] matches { -- miles per hour
magnitude matches {|0..55|}
property matches {"velocity"}
units matches {"mph"}
}
QUANTITY[at0023] matches { -- km per hour
magnitude matches {|0..100|}
property matches {"velocity"}
units matches {"km/h"}
}
}
}

then the data instance created from the at0022 form of the QUANTITY will be
(in dADL):

items = <
["1"] = < -- ELEMENT
archetype_node_id = <"at0004">
value = < --
QUANTITY
archetype_node_id = <"at0022">
magnitude = <25>
>
>
["2"] = <>
etc
>

so the path items[at0004]/value[at0022] will choose the quantity, although
items[at0004]/value would do just as well. (Remember, the Xpath equivalents
are items[@archetype_node_id='at0004']/value[@archetype_node_id='at0022']
etc - the [at0022] is just a shorthand selection predicate.)

The paths are not 'persisted' as such - just the data. The paths are always
derivates of the data.





In case of a query such as get me all Xs where value is expressed as km per
hour, the system can not know what which option was used: kmph or mph,
because there is not node identifier. 


in this case, use the path items[at0004]/value[at0022]. 

- thomas

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

An ACTION or INSTRUCTION referencing an AGEN, is it possible?

[Heath Frankel]

Hi Pablo,
You news to be clearer about the requirement. Depending on the real
requirement the student may be right.
Remember that demographic model is recording instances of parties not
classes. So if the requirement is to record the specific instance of device
recording attributes such serial number, last calibration date etc then he
is perfectly correct to reference this instance using a participation and
party ref.
However if he is just recording the type of device then you would use a
protocol structure as per the blood pressure.
Including an agent object by value within an entry is not allowed and in
cases where we do need to record an instance of a device by value because
we don't want the overhead of first recording the instance in a demographic
repository and then referencing it then we do use the cluster approach that
Heather referred to, but this is an implementation choice or even driven by
the modeling process which wants to use a single model and by value
associations to aid in model understanding. From experience, I don't think
it is absolutely necessary to attempt to model the party model in the
cluster structure, it just makes the model hard to understand and implement.
Heath
On 17/06/2012 12:41 PM, "pablo pazos"  wrote:

>  I'm correcting student papers for the openEHR course in spanish.
> A student has modelled oftalmologic studies for diabetic patients, with a
> demographic archetype of AGENT class to model all the devices used on the
> test.
>
> It could be very usefull to let record the device information in the
> ACTION archetype to say "this is the device we use for this test", or at
> the INSTRUCTION archetype to say "this is the device that should be used
> for the test".
>
> I'm sure some of you have solved this requirement, and I'll be very
> thankful if you can enlight me, because I don't see how the information
> model can solve this.
>
> 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 lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL: 

How about creating an openEHR test base?

[Heath Frankel]

Once again we have tooling to convert csv files to openEHR using template
data schema but someone has to do the hard work of creating the archetypes,
templates and transforms to make it all happen. This continues to be the
blocker of this kind initiative. Let us know if anyone has the bandwidth.
Heath
On 08/05/2012 8:08 PM, "Athanasios Anastasiou" <
athanasios.anastasiou at plymouth.ac.uk> wrote:

> Dear Erik and all
>
> (This email might appear a bit long but it actually makes just two points
> a) Data Synthesizer Tool, b)Availability of Realistic Subject data)
>
> A) Data Synthesizer Tool
> I absolutely agree on the "data synthesizer" tool.
>
> It is something i would like to do as a test case for parsing an
> archetype's definition node and generating a representative object because
> in this case, each and every node defined in the spec would have to be
> handled.
>
> It's not that much of a time consuming task if you already have the RM
> builder. The AM provides everything that is needed (For example:
> http://postimage.org/image/**mcytss26f/bounds
>  for primitive types, cardinality / multiplicity for other data
> structures), so instead of just creating an object from the RM and
> attaching it in a hierarchy (just by calling its constructor maybe), some
> values would have to be generated and attached to its fields as well.
>
> Once the RM object is constructed it can be serialized to anything (XML
> included) (and there goes a first "test base")
>
> From this perspective, it is absolutely essential that the XSDs are valid
> (to ensure a valid structure) and also (Seref's got a very good point) that
> the archetypes are valid to ensure a valid content.
>
> B) Availability of Realistic Subject Data
> As far as clinically realistic datasets are concerned, i would like to
> suggest the following:
>
> The Alzheimer's Disease Neuroimaging Initiative (ADNI) in the US is a long
> term project that collects, longitudinally, various clinical parameters
> from subjects at various stages in the disease (http://adni.loni.ucla.edu/
> ).
>
> At the moment, the dataset contains about 800 subjects. Each subject would
> have 4-5 sessions associated with it (at 6 month intervals usually) and for
> each session a number of parameters would be collected such as MMSE scores,
> ADAS Cog scores, received medication, lab tests and others as well as
> imaging biomarkers (MRI mostly). A basic "demographics" section is also
> available for each subject.
>
> (To put it in the context of a visualisation, the story that these data
> reveal is the progression of AD on a subject / population of subjects which
> is very interesting.)
>
> The data are made available as CSV files (about 12 MB just for the
> numerical data). An application must be made to ADNI to obtain the data. As
> redistribution of the data is prohibited (http://adni.loni.ucla.edu/wp-**
> content/uploads/how_to_apply/**ADNI_DSP_Policy.pdf)
> we would be working towards a tool that would accept a set of ADNI CSV
> files and transform them into a local openEHR enabled repository.
>
> The task here would be to create some archetypes / templates that reflect
> the structure of the data shared by ADNI and then scan the CSVs and
> populate the openEHR enabled repository.
>
> The CSV files are not in the best of conditions (the structure has been
> changed from version to version, certain fields (such as dates) might be in
> a number of different formats, the terminology is not exactly standardised,
> etc).
>
> For us (ctmnd.org) to work on these files we have created an SQL database
> and a set of scripts that sanitize and import the CSVs.
>
> I would be interested in turning this database into an openEHR enabled
> repository (whether a set of XML files or "proper" openEHR database)
> because it can be used for a number of things (especially for testing AQL).
>
> If you think that this can be of help, let me know how we can progress
> with it.
>
> Obviously the tool can be made available to everybody who can then apply
> to download the ADNI data locally.
>
> I am not so sure about the data (even if they become totally anonymised),
> i will have to check, but in any case, going from "I have nothing" to "I
> have a database of multi-modal data from 800 subjects that is more
> realistic than test data" is got to worth the trouble of converting the
> CSVs.
>
> Looking forward to hearing from you
> Athanasios Anastasiou
>
> __**_
> openEHR-technical mailing list
> openEHR-technical at lists.**openehr.org lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL: 

How about creating an openEHR test base?

[Heath Frankel]

Pablo,

This is a good list, I have already commented on 1-3 and I am also
interested 4-6. 

I think a JSON format project would be good to make sure we get consistency
earlier than later, it is not like XML where you can publish a schema and I
suspect various toolkits will have their variations. 

 

Producing test data is a time consuming effort, producing valid instance is
easy enough but at present clinical archetypes are still moving so these get
out of date quickly. The real work is developing know bad instances, because
there are so many ways something can be bad. So we need to define the scope
of this effort and perhaps using the test archetypes on openEHR is not a bad
approach as these may be more stable than the clinical archetypes at this
point. Having said that, perhaps as part of the CKM review process we can
produce test instances that can be made available to CKM users and
developers alike, this could be done at any stage of the review process, not
just at completion.

 

Interoperability testing is extremely important, the IHE process
demonstrates the benefits of this. I have done this with Rong several years
ago and we found a few slight variations and assumptions that we needed to
correlate, again I think we should do this sooner than later before we have
too many systems installed with their own set of assumptions. This really
needs resourcing but I think it should be the vendors that do this since
ultimately they will be beneficiary of having an openEHR compatible system,
but we do need some governance and tooling to support this process so we
need some additional contributions to kick start the process. 

 

I think your initiative is a really good start, it is certainly not a new
idea but you're making it happen, keep it up.

 

Regards

 

Heath

 

From: openehr-technical-boun...@lists.openehr.org
[mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of pablo
pazos
Sent: Monday, 7 May 2012 11:36 PM
To: openeh technical
Subject: RE: How about creating an openEHR test base?

 

Hi Thomas, just to be sure we are on the same page:

 

>From previous emails:

 

What we need is to test our implementations (EHRs, services, repositories,
etc), we don't want to test the tools or the specs (i.e. we will not use an
archetype for a "guitar" concept).

 

We want to concentrate on flat archetypes and operative templates, things
that will be used by systems, not on source ADL archetypes with slots,
abstract types and other things that makes implementation a pain in the
4$$... you know what I mean.

 

 

JSON and other serialization formats should be considered only for transport
purposes, not for modelling, BTW I mentioned only RM instances in JSON, not
archetype instances (but it's possible to transport archetype and templates
using JSON).

 

What I want (and maybe others) is:

 

1. to be sure that RM XSDs are correct compared to the specs,

2. have some RM XML instances are correct validated against XSDs,

3. to have RM XML instances generated for some OTPs, with the referenced
source archetypes and term sets accessible too,

4. create some JSON form of those RM XML instances to play around with REST
services and web browser/javascript apps,

5. create some test cases in our own projects to be sure we are ok, maybe
share those tests and results,

6. maybe do some interoperability tests, e.g. generate some of this
artifacts in one system, transport them to another and see if test cases
pass or not.

 

What do you think guys?

 

Kind regards,

Pablo.

 

  _  

Date: Mon, 7 May 2012 10:30:34 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: How about creating an openEHR test base?

On 06/05/2012 13:28, pablo pazos wrote: 

Hi Peter, thanks for the pointer. 

 

I think this is only ADL related and only 1.5. My idea is to include ADL1.4
and RM instances in XML and JSON, RM & AOM XSD, also term sets.

Maybe we can took some samples from there, but I believe this new repo has a
wider scope. What do you think?


My view is that this existing repository should be expanded to include all
test case archetypes in ADL and any of the other serialised formalisms.
Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think
about what other test case material could be added, and how it should be
organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot
about this in the past and I am sure would have ideas to contribute - Erik
Sundvall has been thinking about some of the other serialisations. I have to
admit to only having seriously thought about test cases for bidirectional
tool processing, which is currently ADL, dADL, and will extend to XML-AOM (I
just haven't gotten around to this yet). 

I have not thought too much about test cases for JSON or YAML, but I have
done the output serialisations for them. Having done the first
implementation of JSON, I think it is too weak a formalism to be seriously
useful

How about creating an openEHR test base?

[Heath Frankel]

Seref,
I think meaningful data is more useful than random maximal or minimal data.
I think that using the template data schema approach could be an easier way
to produce data by hand if a GUI is not available but I am assuming this is
not the case for Pablo.
The Ocean Template Designer is free to download, TDS can be generated, some
work using a good XML tool can produce an instance fairly quickly. The TDD
to openEHR transform is available on openehr.codeplex.com, you can use you
language of choice to load the instance into an XML DOM, validate it
against the schema to inject the default and fixed values and transform to
openEHR.
>From there you will need a bit more OPT and RM validation but you will be
90% of the way (especially if you use my further constrained version of
basetypes.xsd, which I might make available on codeplex along with the
transform).
Heath
On 07/05/2012 11:56 PM, "Seref Arikan" 
wrote:

> I don't have the time to do what I'm going to suggest next, but if someone
> has time in their hands, I'd suggest writing a tool that will automatically
> generate valid XML RM documents, such as compositions etc.
>
> Archetypes and templates define boundaries of all valid instances of
> clinical models, and one can generate random instances that belong to this
> set. Opereffa's current version supports this, but not with XML output. I
> used this approach to test performance of persistence options
>
> If our argument is that all the clinical information can be represented
> via models, why should be create RM instances by hand?
>
> Regards
> Seref
>
>
> On Mon, May 7, 2012 at 3:05 PM, pablo pazos wrote:
>
>>  Hi Thomas, just to be sure we are on the same page:
>>
>> From previous emails:
>>
>> *What we need is to test our implementations (EHRs, services,
>> repositories, etc), we don't want to test the tools or the specs (i.e.
>> we will not use an archetype for a "guitar" concept).*
>> *
>> *
>> *We want to concentrate on flat archetypes and operative templates,
>> things that will be used by systems, not on source ADL archetypes with
>> slots, abstract types and other things that makes implementation a pain in
>> the 4$$... you know what I mean.*
>>
>>
>> JSON and other serialization formats should be considered only for
>> transport purposes, not for modelling, BTW I mentioned only RM instances in
>> JSON, not archetype instances (but it's possible to transport archetype and
>> templates using JSON).
>>
>> What I want (and maybe others) is:
>>
>> 1. to be sure that RM XSDs are correct compared to the specs,
>> 2. have some RM XML instances are correct validated against XSDs,
>> 3. to have RM XML instances generated for some OTPs, with the referenced
>> source archetypes and term sets accessible too,
>> 4. create some JSON form of those RM XML instances to play around with
>> REST services and web browser/javascript apps,
>> 5. create some test cases in our own projects to be sure we are ok, maybe
>> share those tests and results,
>> 6. maybe do some interoperability tests, e.g. generate some of this
>> artifacts in one system, transport them to another and see if test cases
>> pass or not.
>>
>> What do you think guys?
>>
>> Kind regards,
>> Pablo.
>>
>> --
>> Date: Mon, 7 May 2012 10:30:34 +0100
>> From: thomas.beale at oceaninformatics.com
>> To: openehr-technical at lists.openehr.org
>>
>> Subject: Re: How about creating an openEHR test base?
>>
>> On 06/05/2012 13:28, pablo pazos wrote:
>>
>>  Hi Peter, thanks for the pointer.
>>
>>  I think this is only ADL related and only 1.5. My idea is to include
>> ADL1.4 and RM instances in XML and JSON, RM & AOM XSD, also term sets.
>> Maybe we can took some samples from there, but I believe this new repo
>> has a wider scope. What do you think?
>> *
>> *
>>
>>
>> My view is that this existing repository should be expanded to include
>> all test case archetypes in ADL and any of the other serialised formalisms.
>> Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think
>> about what other test case material could be added, and how it should be
>> organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a
>> lot about this in the past and I am sure would have ideas to contribute -
>> Erik Sundvall has been thinking about some of the other serialisations. I
>> have to admit to only having seriously thought about test cases for
>> bidirectional tool processing, which is currently ADL, dADL, and will
>> extend to XML-AOM (I just haven't gotten around to this yet).
>>
>> I have not thought too much about test cases for JSON or YAML, but I have
>> done the output serialisations for them. Having done the first
>> implementation of JSON, I think it is too weak a formalism to be seriously
>> useful, because it lacks too many basic semantics - particularly dynamic
>> type markers. Its cousin YAML is over-complicated (and in its whitespace
>> form, nearly impossible to get right!), but does have proper OO

How about creating an openEHR test base?

[Heath Frankel]

Hi Pablo,
What issues do you have with the XSD? We have been producing valid
instances for years. I have tools that can validate these in seconds. I am
sitting on hundreds of test instances. Problem is I am not sitting around
with nothing to do. If you have a student willing to do some dot NET code
with little support you can go to openehr.codeplex.com to get what you need
to create and validate openehr instances against OPTs and RM.

BTW, I have a local xsd that further constrains the published schema that
picks up several additional RM invariants. Happy to contribute this but
don't want to confuse the status of the official schema. I also have a
demographic schema which I believe is currently not part of the current
openEHR release.
Heath
On 08/05/2012 12:09 AM, "pablo pazos"  wrote:

>  Hi Seref, I've a tool that generates composition instances from
> archetypes and data, what I don't have is a way to generate a valid XML
> form from those compositions.
>
> In order to do that, we should resolve current reported issues with the
> XSDs (see my first email), and then generate XMLs, at first maybe by hand,
> later integrated into tools.
>
> --
> 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, 7 May 2012 15:26:28 +0100
> Subject: Re: How about creating an openEHR test base?
> From: serefarikan at kurumsalteknoloji.com
> To: openehr-technical at lists.openehr.org
>
> I don't have the time to do what I'm going to suggest next, but if someone
> has time in their hands, I'd suggest writing a tool that will automatically
> generate valid XML RM documents, such as compositions etc.
>
> Archetypes and templates define boundaries of all valid instances of
> clinical models, and one can generate random instances that belong to this
> set. Opereffa's current version supports this, but not with XML output. I
> used this approach to test performance of persistence options
>
> If our argument is that all the clinical information can be represented
> via models, why should be create RM instances by hand?
>
> Regards
> Seref
>
>
> On Mon, May 7, 2012 at 3:05 PM, pablo pazos wrote:
>
>  Hi Thomas, just to be sure we are on the same page:
>
> From previous emails:
>
> *What we need is to test our implementations (EHRs, services,
> repositories, etc), we don't want to test the tools or the specs (i.e. we
> will not use an archetype for a "guitar" concept).*
> *
> *
> *We want to concentrate on flat archetypes and operative templates,
> things that will be used by systems, not on source ADL archetypes with
> slots, abstract types and other things that makes implementation a pain in
> the 4$$... you know what I mean.*
>
>
> JSON and other serialization formats should be considered only for
> transport purposes, not for modelling, BTW I mentioned only RM instances in
> JSON, not archetype instances (but it's possible to transport archetype and
> templates using JSON).
>
> What I want (and maybe others) is:
>
> 1. to be sure that RM XSDs are correct compared to the specs,
> 2. have some RM XML instances are correct validated against XSDs,
> 3. to have RM XML instances generated for some OTPs, with the referenced
> source archetypes and term sets accessible too,
> 4. create some JSON form of those RM XML instances to play around with
> REST services and web browser/javascript apps,
> 5. create some test cases in our own projects to be sure we are ok, maybe
> share those tests and results,
> 6. maybe do some interoperability tests, e.g. generate some of this
> artifacts in one system, transport them to another and see if test cases
> pass or not.
>
> What do you think guys?
>
> Kind regards,
> Pablo.
>
> --
> Date: Mon, 7 May 2012 10:30:34 +0100
> From: thomas.beale at oceaninformatics.com
> To: openehr-technical at lists.openehr.org
>
> Subject: Re: How about creating an openEHR test base?
>
> On 06/05/2012 13:28, pablo pazos wrote:
>
>  Hi Peter, thanks for the pointer.
>
>  I think this is only ADL related and only 1.5. My idea is to include
> ADL1.4 and RM instances in XML and JSON, RM & AOM XSD, also term sets.
> Maybe we can took some samples from there, but I believe this new repo has
> a wider scope. What do you think?
> *
> *
>
>
> My view is that this existing repository should be expanded to include all
> test case archetypes in ADL and any of the other serialised formalisms.
> Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think
> about what other test case material could be added, and how it should be
> organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a
> lot about this in the past and I am sure would have ideas to contribute -
> Erik Sundvall has been thinking about some of the other serialisations. I
> have to admit to only having serious

How about creating an openEHR test base?

[Heath Frankel]

Hi Erik,
I think that using an EHR service to store RM instances would be better
than storing in SVN or GIT. Ultimately if the service was able to work from
a GIT repository we would have the best of both worlds.
I had considered offering the Ocean EHR server but I assumed the usual
issues relating to the commercial backend would have made this not suitable
so I didn't bother.
Would your service be an alternative, especially since it is RESTful?
Perhaps there is a need for multiple service implementations to be
available working from the same instance repository, I am sure each have
their strengths and weaknesses and interface approaches. For example the
ocean EHR service picked up a data validation error reported on the list
that another didn't.
We can also use this to start comparing service models.
Heath
On 07/05/2012 4:32 PM, "Erik Sundvall"  wrote:

> Hi!
>
> I agree that we need some RM instances etc initially. We have
> versioned compositions in the demo server for our LiU EEE-system. We
> don't know if they are 100% according to spec since they have not been
> extensively tested. I'll upload some of them to the wikipage after a
> deadline I have this week (remind me if they are not there next monday
> ;-)  I can give a limited number of people access to them now via
> REST-interfaces (HTTP via a browser works fine).  Mail me off-list if
> you are in a hurry.
>
> Would EHR-data reflecting a number realistic patient stories be
> interesting to collaborate on as a second step? I am in desperate need
> of such EHR data in order to create and test EHR-visualisations.
> Getting "real" patient data is a pain to get access to and if we get
> it we can never share it. Could we share the effort of creating a
> number of such EHR instances (and perhaps write a shared academic
> paper about it) - If so let's first check/discuss some of the options
> for data entry and once that is fixed we can involve more clinicians
> to create and improve/review the stories. A shared set could be reused
> in several projects and make them more comparable too.
>
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
>
>
> On Mon, May 7, 2012 at 12:48 AM, pablo pazos 
> wrote:
> > Hi Diego & Peter,
> >
> > What Diego said about evolving tests for ADL1.5 is true, we don't want to
> > test the tools or the specs, we want to test our implementations (EHRs,
> > services, repositories, etc).
> >
> > I agree this overlaps in some way with the CKM content (archetypes and
> > templates), but our focus is on flat archetypes and operative templates,
> > things that will be used by systems, not on source ADL archetypes with
> > slots, abstract types and other things that makes implementation a pain
> in
> > the 4$$... you know waht I mean.
> >
> > I agree what Diego said in the last message: we want RM instances (XML)
> in
> > the repo, which will be valid against XSDs (that we need to test and fix,
> > XSDs will be included in the repo too). JSON instances will be welcome
> too
> > :D
> >
> > To give more context, this is taken from a private message to Erik:
> >
> > What I have in mind is to create something like a unit test for openEHR
> > applications and services, with archetypes, rm instances and term sets.
> E.g.
> > having a test set with some archetypes, a template, some term sets and a
> > couple of instances in xml and json formats, and create some small
> software
> > that can handle those test sets, validating instances to schemas,
> validating
> > structures to archetypes, etc. and maybe geting data from the instances
> and
> > doing something with it, 
> >
> >
> > --
> > 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: yampeku at gmail.com
> >> Date: Mon, 7 May 2012 00:23:44 +0200
> >
> >> Subject: Re: How about creating an openEHR test base?
> >> To: openehr-technical at lists.openehr.org
> >
> >>
> >> Pablo also mentioned 'RM instances in a variety of formats', which are
> >> not 'artefacts'.
> >>
> >> 2012/5/7 Peter Gummer :
> >> > Diego Bosc? wrote:
> >> >
> >> >> I would say the scope of that repository is different, as that is
> part
> >> >> of the test for current evolving 1.5 syntax and does not include
> >> >> 'real' archetypes
> >> >
> >> > My understanding was that Pablo was not proposing real archetypes
> >> > either. In his original post, Pablo proposed a "test base with sample
> >> > artifacts".
> >> >
> >> > How would this be different from the purpose of the existing
> >> > http://www.openehr.org/svn/knowledge2 repository? The only
> difference that I
> >> > can see is that Pablo has proposed adding a greater variety of
> artefacts
> >> > (OPTs, etc.), so it seems natural to add them to the existing
> repository.
> >> >
> >> > - Peter
> >
> > ___
> > 

TerminologyId.Name

[Heath Frankel]

Hi Leykum,

Looking at your instance closely you will see that you have a ?gastric 
interventions? ACTION with a ism_transition current_state as follows:

 



Completed






532




openehr





 

You will notice that your terminology_id value is 532 and code_string is 
openehr, which are transposed from what is expected. This occurs again in your 
Diagnosis value in Diagnosis EVALUATION, terminology_id value is C180, 
code_string is ICD10).

 

The Ocean RM validator, which is obviously being used here (I notice the 
invariant message style)  is applying the RM invariants on the TEMINOLOGY_ID 
class that state that the terminology ID must start with a letter and its 
internal RegEx pattern matching used to extract the terminology name from the 
terminology_id value has failed to return a match, which results in a RM 
invariant check on the terminology name to fail. 

 

Although the message is not quite right, having a tight invariant checker 
certainly helps in picking up invalid data even if it is not that obvious that 
it is wrong (some still slip through as will be the case in the diagnosis value 
unless you have a template constraint on the terminology value).

 

Regards

 

Heath

 

From: openehr-technical-bounces at lists.openehr.org 
[mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Leykun Melkamu
Sent: Wednesday, 25 April 2012 6:18 PM
To: For open EHR technical discussions
Subject: TerminologyId.Name

 

Hi

 

I was trying to build compositions from xml files and when I try to Commit the 
composition I get the exception TerminologyId.Name must not be null or emtpy.

 

I think the problem is in the xml file corresponding to the  action archetype 
but I don?t know where to set the value for that element. Can I get some 
information from you thanks for your help and time. I have attached the xml 
composition 

 

Best regards ,

Leykun  

 

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

Suggestion to replace use of generics with inheritence in future RM versions

[Heath Frankel]

Ok, thanks for the clarification.

Heath
On 23/03/2012 10:28 PM, "Seref Arikan" 
wrote:

> Hi Heath,
> Just to clarify: my original issue is not about auto generation of classes
> from XSD, whether or not one choses to do that is irrelevant if the XSD
> itself is not supporting generics. The problem is with the XSD (not having
> support for generics) and it may or may not cascade to programming language
> space.
>
> Separately, I agree with  you on not taking XSD and code generation as the
> basis of RM implementation, and I am neither following nor suggesting this
> route.
>
> At the moment, I am connecting Rong's implementation to JAXB, which is my
> choice of design to handle XML related functionality in Java RM.
>
> I find these discussions very helpful, even though they have a tendency to
> fork, but hey, this is why have the groups :)
>
> Kind regards
> Seref
>
>
> On Fri, Mar 23, 2012 at 12:09 PM, Heath Frankel <
> heath.frankel at oceaninformatics.com> wrote:
>
>> I think the topic has drifted slight from Seref's original issue,
>> although Java nor c# can not implement generics as well as Eiffel or as
>> intended by the spec author it is possible to get close enough to be
>> usable. Similar implementation decisions were necessary when specifying the
>> XML schema and again it is close enough to be usable.
>> My understanding of Seref's original issue is the auto generation of Java
>> classes from the XML schema using frameworks like jaxb and .Net. I
>> personally think this is the wrong way around when it comes to the RM
>> classes.  I know every developer can do it better than the next but any
>> developer can do it better than a tool. If you are going to invest in
>> implementing openEHR you should take the time to get a good implentation of
>> the building blocks by adopting and contributing to an existing
>> implementation in your preferred language or do it yourself better than
>> everyone else.
>> Cutting corners by using a tool will result in you throwing away the
>> approach and doing it properly later anyway (been there done that).
>> The only tool that maybe plausible is an openEHR specific class generator
>> for writing jaxb web services that are driven from AOM, not some generic
>> XML tool that is not designed to handle the genericity and use of abstract
>> types as used in openEHR and not able to be expressed in XML schema.
>> Ocean has been auto generating template data schema and template data
>> classes for use in working systems for several years, they provide great
>> benefit but need further work to make the generated artifacts simpler,
>> flatter and more usable including with tools such as jaxb and mapforce. We
>> need help to make this happen.
>> The problem is that everytime we remove complexity we come across a
>> requirement for the complexity and end up with something closer to the RM
>> again.
>> So yes we need to make the entry point to use openEHR lower,  but we do
>> this by comprising the capability of the resulting solution.
>>
>> Anyway in conclusion I believe we need to keep the RM specs logical, have
>> technical specs for serialisation such as XML and ADL, class
>> implementations in strongly typed OO languages and dynamic languages.
>> Persistence is another technical group of specs. But I think we should not
>> mix serialization with class implematation or persistence, except for
>> stating an anti pattern of using XML tools to generate a class
>> implementation.
>>
>> Heath
>> On 23/03/2012 12:11 AM, "Seref Arikan" <
>> serefarikan@?kurumsalteknoloji.com >
>> wrote:
>>
>>> I should have been more specific. Generics in collections is a managable
>>> issue :) and yes, I would not like to go back to non-generic collections
>>> either..
>>>
>>>
>>> On Thu, Mar 22, 2012 at 2:26 PM, Thomas Beale <
>>> thomas.beale@?oceaninformatics.com >> oceaninformatics.com>>wrote:
>>>
>>>>
>>>> I have to say, software development would be absolutely dire from my
>>>> point of view without one particular generic type: Hash. That really
>>>> would destroy nearly every class I have ever written!
>>>>
>>>> - thomas
>>>>
>>>>
>>>> On 22/03/2012 01:47, Shinji KOBAYASHI wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> 2012/3/22 Peter Gummer  >>> at oceaninformatics.com>:
>>>>
>>>>  Shinji KOBAYASHI wrote:
>>>>
>>>>
>&

Suggestion to replace use of generics with inheritence in future RM versions

[Heath Frankel]

I think the topic has drifted slight from Seref's original issue,  although
Java nor c# can not implement generics as well as Eiffel or as intended by
the spec author it is possible to get close enough to be usable. Similar
implementation decisions were necessary when specifying the XML schema and
again it is close enough to be usable.
My understanding of Seref's original issue is the auto generation of Java
classes from the XML schema using frameworks like jaxb and .Net. I
personally think this is the wrong way around when it comes to the RM
classes.  I know every developer can do it better than the next but any
developer can do it better than a tool. If you are going to invest in
implementing openEHR you should take the time to get a good implentation of
the building blocks by adopting and contributing to an existing
implementation in your preferred language or do it yourself better than
everyone else.
Cutting corners by using a tool will result in you throwing away the
approach and doing it properly later anyway (been there done that).
The only tool that maybe plausible is an openEHR specific class generator
for writing jaxb web services that are driven from AOM, not some generic
XML tool that is not designed to handle the genericity and use of abstract
types as used in openEHR and not able to be expressed in XML schema.
Ocean has been auto generating template data schema and template data
classes for use in working systems for several years, they provide great
benefit but need further work to make the generated artifacts simpler,
flatter and more usable including with tools such as jaxb and mapforce. We
need help to make this happen.
The problem is that everytime we remove complexity we come across a
requirement for the complexity and end up with something closer to the RM
again.
So yes we need to make the entry point to use openEHR lower,  but we do
this by comprising the capability of the resulting solution.

Anyway in conclusion I believe we need to keep the RM specs logical, have
technical specs for serialisation such as XML and ADL, class
implementations in strongly typed OO languages and dynamic languages.
Persistence is another technical group of specs. But I think we should not
mix serialization with class implematation or persistence, except for
stating an anti pattern of using XML tools to generate a class
implementation.

Heath
On 23/03/2012 12:11 AM, "Seref Arikan" 
wrote:

> I should have been more specific. Generics in collections is a managable
> issue :) and yes, I would not like to go back to non-generic collections
> either..
>
>
> On Thu, Mar 22, 2012 at 2:26 PM, Thomas Beale <
> thomas.beale at oceaninformatics.com> wrote:
>
>>
>> I have to say, software development would be absolutely dire from my
>> point of view without one particular generic type: Hash. That really
>> would destroy nearly every class I have ever written!
>>
>> - thomas
>>
>>
>> On 22/03/2012 01:47, Shinji KOBAYASHI wrote:
>>
>> Hi Peter,
>>
>> 2012/3/22 Peter Gummer  > oceaninformatics.com>:
>>
>>  Shinji KOBAYASHI wrote:
>>
>>
>>  Ruby implementation might be one of the proof for replace of generics.
>> I had much struggled to implement generics and got the conclusion
>> that we do not need it.
>>
>>  Ruby doesn't have generics at all, right, Shinji?
>>
>>  It is right. I felt generics is very convenient, when I used Java, such as
>>
>>  Iterator it = someRmArrayInstance.iterator()
>>
>> But I found it must be cut off by 'Occam's razor' in Ruby.
>>
>>  it = some_rm_array.iterator
>>
>> This code looks curious for Java/Eiffel/C# user who are similar to generics,
>> but it is enough for encapsulated object instance.
>> I think this depends on language environment, but nested generics seems
>> complicated codes for me.
>>
>>  List >
>>
>> Generics is useful to declare what instance is, but it breaks encapsulation.
>> As regards to Bartrand Meyer's paper, 'a good balance' is a good design.
>>
>> Cheers,
>> Shinji
>>
>>
>>  There's a comparison of generics and inheritance in an appendix of Bertrand 
>> Meyer's "Object Oriented Software Construction", 2nd edition. 
>> (http://se.ethz.ch/~meyer/?publications/acm/geninh.pdf 
>>  seems to be the 
>> original paper that the appendix is based upon.)
>>
>> Generics can be simulated in a language with inheritance, but there is a 
>> cost:
>> * Duplication of code.
>> * Extra verbosity.
>>
>> I don't want to have either forced upon me. If I'm unfortunately forced to 
>> use a language that doesn't support generics, then I can always simulate it 
>> the generics with inheritance. But I certainly wouldn't want the specs to be 
>> obfuscated by hacks like that, thanks very much ;-)
>>
>> Peter
>> __?_
>> openEHR-technical mailing list
>> openEHR-technical at lists.?openehr.org > lists.openehr.org>http://lists.openehr.org/?mailman/listinfo/openehr-?technical_lists.openehr.org
>>  

Units, Quantities, etc

[Heath Frankel]

Hi Thomas,

I had an issue recently were I was receiving HL7 V2 Lab messages with units 
such as x10^6/L, the equivalent in UCUM is 10*6/l, which was used in the 
archetype constraint for an RBC element. I translated the HL7 unit into the 
archetype constrained unit as required to be valid.

However, when we displayed this in our application that was going through a 
conformance process for this particular Lab?s interface to allowed to retrieve 
messages within the enterprise, the Lab said that we *must* display the unit as 
x10^6/L as provided in the HL7 message. Therefore we had to translate it back 
again in our app? sigh.

 

This scenario demonstrates this exact conversation.

 

Personally I don?t like the idea of another attribute for displayable units.  I 
am thinking that we need to have a means to lookup a particular set of 
?displayable? units and get the computable unit for when we need to do any 
conversion, which I have yet to come across any need to do so in current 
implementations (not that this will not be required at some point but it will 
certainly be in very limited set of cases).

 

I am thinking the units attribute should be our ?displayable?, and tat in cases 
where we need to convert to other units we provide a similar concept to 
mappings in DV_TEXT. Perhaps this should be the reverse, but because the 
displayable unit is the 99.99% use case I think we should make this the easiest 
representation with minimal change to RM. 

 

In archetypes, if the units attribute is allowed to any value, we can then 
specify a conversion mapping for each unit, which may allow multiple 
?displayable? units to be defined and mapped to the same UCUM unit.  So this 
conversion mapping is represented as knowledge in the archetype, but we also 
start getting some consistent representation of ?displayable? units without the 
weirdness of UCUM syntax.

 

Hope this triggers further thoughts.

 

Heath

 

From: openehr-technical-bounces at lists.openehr.org 
[mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale
Sent: Sunday, 18 March 2012 10:49 PM
To: Openehr-Technical
Subject: Units, Quantities, etc

 


As Grahame mentioned on an earlier post, the question of units is thorny. 
Although we technical people would like to mandate UCUM or some other 
well-designed computable syntax, on its own, it won't work. There seem to be 
two reasons for this:

*   it doesn't take care of the need for a displayable form of units, e.g. 
the computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu 
followed by 'g')
*   it doesn't take care of 'units' like puffs, tablets, patches, vials, 
strips, and other discrete delivery units
*   it doesn't take care of discrete delivery units per time, e.g. '2 puffs 
/ hour'

Grahame and others have already done a lot of thinking on this here 

  - there are a lot of excellent examples from Linda Bird on the Singapore 
programme.

The more I think about the last two above, the more I think it is not about 
quantities per se but about an administration directive (how the patient should 
take something). Trying to make Quantity do that kind of stuff doesn't make 
sense to me - there is obviously a Quantity to indicate the dose in scientific 
form, but another data element may be needed to indicate how (in what discrete 
measures) to take the medication.

I would therefore expect a distinct data element in the Medication Cluster 
archetype rather than a re-engineered Quantity type to deal with these last 
two. For the first one - displayable v computable, we will need a CR to change 
DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units 
field.

Some of my earlier thoughts are actually on the above wiki page - the concept 
of a DiscretisedQuantity type inheriting from Quantity, which I think is also a 
reasonable alternative.

what do others think?

- thomas

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

openEHR - Persistence of Data

[Heath Frankel]

Hi Koray,
Yes there was a honours thesis done on using an object database to store
and query openEHR data. It was intended to compare our indexed XML blob
approach but from memory it ended up comparing two commercial object
databases.
I will have to ask Chunlan if the paper is publicly available.

Heath.
On 20/02/2012 8:54 PM, "Koray Atalag"  wrote:

>  I remember a Honours or Master?s thesis on openEHR persistence...I think
> Heath was involved. Heath is that publicly available?
>
> ** **
>
> Cheers,
>
> ** **
>
> -koray
>
> ** **
>
> *From:* openehr-technical-bounces at openehr.org [mailto:
> openehr-technical-bounces at openehr.org] *On Behalf Of *M?rcio Costa
> *Sent:* Saturday, 18 February 2012 10:36 a.m.
> *To:* For openEHR technical discussions
> *Subject:* Re: openEHR - Persistence of Data
>
> ** **
>
> Do Anyone knows about some papers of persistent storing? 
>
> ** **
>
> att,
>
>
> *M?rcio Costa*
> B.Sc. in Computer Science @ Cin/UFPE
> M.Sc. Candidate in Computer Science @ CIn/UFPE
> MSN: mdckoury at gmail.com
>
>
> 
>
> Em 17 de fevereiro de 2012 17:59, M?rcio Costa 
> escreveu:
>
> i would like to thank everyone for the information and attention. 
>
> ** **
>
> i'm trying to do a review about this subject to start my research, but i
> will do something to analyse the best way to model and persist this kind of
> data.
>
> ** **
>
> Best Regards,
>
> ** **
>
> *M?rcio Costa*
> B.Sc. in Computer Science @ Cin/UFPE
> M.Sc. Candidate in Computer Science @ CIn/UFPE
> MSN: mdckoury at gmail.com
>
>
> 
>
> 2012/2/17 pablo pazos 
>
> Hi Erik, you are right, the uglyness depends on 1. the queries you want to
> execute and 2. the programmer background.
>
> ** **
>
> For 1. the "common" queries like get all records for this patient in this
> time window, are not that ugly, but more complex queries could be.
>
> For 2. for a XML guy, writing xPath based queries is ok, but for a SQL is
> a pain in the a55.
>
> :D
>
> I'm hoping to see that paper on AQL->xQuery soon!
>
> ** **
>
> I totally agree that inside the system maybe you don't need a complete RM
> structure to handle data instances, but for the service layer (sharing
> information with other systems) this is a must.
>
>
>
> --
> Kind regards,
> Ing. Pablo Pazos Guti?rrez
> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
> Blog: http://informatica-medica.blogspot.com/
> Twitter: http://twitter.com/ppazos
>
> > Date: Fri, 17 Feb 2012 16:21:29 +0100
> > Subject: Re: openEHR - Persistence of Data
> > From: erik.sundvall at liu.se
> > To: openehr-technical at openehr.org
>
>
> >
> > Hi!
> >
> > On Thu, Feb 16, 2012 at 23:26, pablo pazos 
> wrote:
> > > Other models I didn't try yet are Object Oriented DBs and
> > > Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs
> > > are a good option, fast for store highly hierarchical structures,
> > > but you need to write some ugly queries if you want your data back :D
> >
> > Not necessarily that ugly... we curently auto-convert AQL to XQuery
> > and execute towards an XML database. Those queries are very readable.
> >
> > Then the question is what kind of client system you are aiming at. For
> > some use cases you don't really need to map things back to
> > openEHR-RM-objects, in web browser based GUIs for example you can keep
> > treating the data as documents, document fragments, fragment lists
> > etc. and use DOM manipulations, jQuery or similar approaches for most
> > data manipulation needs.
> >
> > Good luck with your work M?rcio and please keep us informed!
> >
> > Best regards,
> > Erik Sundvall
> > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
> ** **
>
> ** **
>
> ** **
>
> __ Information from ESET NOD32 Antivirus, version of virus
> signature database 6898 (20120220) __
>
> ** **
>
> The message was checked by ESET NOD32 Antivirus.
>
> ** **
>
> http://www.eset.com
>
>
> __ Information from ESET NOD32 Antivirus, version of virus
> signature database 6898 (20120220) __
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
> ___
> 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: 

Meaningful Use and Beyond - O'Reilly press - errata

[Heath Frankel]

Considering the incorrect reference to openEHR in the author's CTO
position, without knowing conext of were it is done, perhaps all references
were intended to be to openEMR?

Heath
On 12/02/2012 11:31 PM, "Thomas Beale" 
wrote:

>
> It would be interesting to see what US-based list members think of what
> Michael has quoted below. Is openEHR really seen as 'controversial' in the
> US? (Controversy can be good - at least it means debate).
>
> The quote below about David Uhlman being CTO of openEHR in 2001 is
> certainly incorrect - I imagine it is supposed to read 'OpenEMR', going by
> what I see here  in Wikipedia
> (in any case, openEHR has never had a 'CTO' position). That's a
> surprisingly bad fault in O'Reilly editing; worse, the author page for
> David Uhlman  on the O'Reilly
> website repeats the same error. This 
> reviewon the 
> same website seems to confirm a complete lack of review or editing
> of the original manuscript. O'Reilly obviously is missing basic mechanisms
> for quality control.
>
> But the more interesting question is: are the opinions in this book about
> openEHR representative of a US view?
>
> - thomas
>
> On 12/02/2012 11:22, Michael Osborne wrote:
>
> I read the recently released O'Reilly book "Meaningful Use and Beyond" on
> Safari books today and found the following errors
> and some quite blatantly false statements about OpenEHR.
>
>  Firstly is the claim by one of the authors, David Uhlman, that he was
> CTO of openEHR in 2001
>  - a claim which Thomas Beale denies.
>
>  *
> David Uhlman is CEO of ClearHealth, Inc., which created and supports
> ClearHealth,
> the first and only open source, meaningful use-certified, comprehensive,
> ambulatory
> EHR David entered health-care in 2001 as CTO for the OpenEHR project.
>  One of the first companies to try commercializing open source healthcare
> systems
> , OpenEHR met face first with the difficult realities of bringing proven
> mainstream
> technologies into the complicated and some-
> *
> *times nonsensical world of healthcare.*
> *
> *
> Secondly, a nonsensical statement about openEHR in the book...
>  p.161
>  *OpenGALEN and OpenEHR are both attempts to promote open source ontology
> con-*
> *cepts. Both of the projects have been maturing but some view these as
> unnecessary*
> *additions or alternatives to SNOMED+UMLS. However, they are available
> under open*
> *source licensing terms might make them a better alternative to SNOMED
> for certain*
> *jurisdictions.*
>
>  And this, p163...
>
>  *OpenEHR is a controversial approach to applying knowledge engineering
> principles*
> *to the entire EHR, including things like the user interfaces. You might
> think of Open-*
> *EHR as an ontology for EHR software design. Many health informaticists
> disagree on*
> *the usefulness of OpenEHR. Some believe that HL7 RIM, given its
> comprehensive*
> *nature, is the highest level to which formal clinical knowledge managing
> needs to go.*
>  *
> *
> I'm beginning to lose all respect for O'Reilly press. It's been all
> downhill since the camel book.
>
>  Cheers
> Michael Osborne
> *
> *
>
>
>  --
> Michael Osborne
>
>
> ___
> openEHR-technical mailing listopenEHR-technical at 
> openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>  *
> *
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Building software to convert HL7 v2/v3 messaging into archetypes & templates

[Heath Frankel]

Hi Paulo,
The question is, what are you going to do with the lab report once it is
transformed. If you are storing it in an openEHR repository then the is no
demographics required in the report. However you do need to find the EHR to
store it in, possibly create a demographic record and EHR for the subject.
What is necessary is dependent on how you process this workflow. If you use
mirth then you don't need to transform it as you can use the source data
unless you need to create a demographic record in which case you perform
the same process to do this.
If you are transforming to an EHR extract or similar then you need a
wrapper for the TDD with a subject details structure.
We use this later approach for both scenarios because it allows us to
define a template data service process independent of any particular
integration service.

Heath
On 10/02/2012 3:42 AM, "Paulo Ferreira"  wrote:

> Hello all,
>
> I'm working on my thesis project, which one of the components is
> EHRstorage in a openEHR repository. Since the input is HL7v2.x messages
> there isthe necessity of openEHR conversion. I think Heath remembers me,
> because Heath andChunlan helps me with this issue. I was capable to
> assemble a small prototypethat includes Mirth, which invokes a Java
> implementation environment to performthe conversion.
> The clinical data that that is present in an Unsolicited ObservationResult
> (ORU^R01) for instance, it?s successfully converted, but withoutdemographic
> data, neither a patient identification instance. Can you give someclue
> about this topic?
>
> Best Regards,
> Paulo Ferreira.
>
> ___
> 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: 

Python / Django experience??

[Heath Frankel]

So this sounds like a knowledge index service rather than a repository. Is
this where you get the correlation with RLUS?
Heath
On 01/02/2012 7:51 PM, "Ian McNicoll" 
wrote:

> Hi Heath,
>
> RLUS, as I understand it is designed to operate with EHR instance
> data, rather than knowledge artefacts, so is not suitable per-se, but
> there is a fair degree of cross-over in some of the querying and
> location requirements and it might serve as a decent start point for
> discussion.
> but are there other 'standards' that are more applicable to
> distributed knowledge repositories.
>
> Basic requirements
>
> 1. Query across multiple repositories using multiple criteria, based
> on something similar to the CKM ontology.
> 2. Establish references to remote assets, almost certainly caching the
> referenced asset locally
> 3. Establish subscriptions to remote assets, to enable change notification
> etc
>
> 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
> Director/Clinical Knowledge Editor openEHR Foundation
> www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> SCIMP Working Group, NHS Scotland
> BCS Primary Health Care  www.phcsg.org
>
>
>
> On 31 January 2012 23:00, Heath Frankel
>  wrote:
> > Hi Ian,
> > Interested in how you think RLUS can support a Knowledge service?
> > Heath
> >
> > On 01/02/2012 2:21 AM, "Ian McNicoll"  >
> > wrote:
> >>
> >> Hi Pablo,
> >>
> >> Your initial ideas on a possible service layer would be very
> >> interesting. I think we are starting to see a need to support cross
> >> repository service layer but possibly split between formally governed
> >> assets and those that are in early or experimental stages of
> >> development (as we envisage with CKI). The requirements for governed
> >> cross-repository assets will be rather more demanding.
> >>
> >> Have you seen this HL7/OMG proposal?
> >>
> >> http://hssp-rlus-normative.wikispaces.com/home
> >>
> >> Might be a useful start point.
> >>
> >> 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
> >> Director/Clinical Knowledge Editor openEHR Foundation
> >>  www.openehr.org/knowledge
> >> Honorary Senior Research Associate, CHIME, UCL
> >> SCIMP Working Group, NHS Scotland
> >> BCS Primary Health Care  www.phcsg.org
> >>
> >>
> >>
> >> On 31 January 2012 15:27, pablo pazos  wrote:
> >> > Hi Ian, it would be nice to share a common API or service layer that
> >> > both
> >> > groups can rely on, so we can make our tools compatible in some way.
> >> > I have an informal list of requirements that this tool should support,
> >> > maybe
> >> > we can start sharing our requirements and see if we can agree on a
> >> > common
> >> > interface (API/services).
> >> >
> >> >
> >> > --
> >> > 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: Tue, 31 Jan 2012 14:57:20 +
> >> >> Subject: Re: Python / Django experience??
> >> >
> >> >> To: openehr-technical at openehr.org
> >> >>
> >> >> Thanks Pablo,
> >> >>
> >> >> I will be interested to see how your app develops. We have a few
> >> >> Python volunteers so hope to have something visibly quite soon.
> >> >>
> >> >> 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

Building software to convert HL7 v2/v3 messaging into archetypes & templates

[Heath Frankel]

Hi Wo,

Not sure if anyone else has some tools for the Job, but my experience in
doing this over the last 5 years is that there is no silver bullet for this
task.  The process is just like any integration mapping, however the
commercial mapping tools that I have attempted to use and those I have
attempted to build myself just don't give me the capability needed for the
mapping complexity I require.  One of the ley issues is support for abstract
types.  I would be very happy to know if others have found a better tool
than those I have tried

I write XSLT by hand to transform the input message (HL7 V2 needs to be
converted to XML using an integration component such as Mirth) into a
Template Data Document (TDD) as defined in my presentation.  The TDD is
validated against the Template Data Schema (TDS) generated from a Template
defined in the Ocean Template Designer, which augments the document with
fixed and default values in the schema.  The validated TDD  is then
transformed using a TDD to openEHR composition transform that can be used
for any template exported using the Ocean Template Designer. These
transforms are applied within an integration service which also provides
communication ports and message tracing. 

 

You could certainly skip the intermediate TDD step but we have found that
using it provides a more concrete (domain) model of the message that you are
transforming to and allows the use of standard XML schema validation tools
to catch 95% of the structural errors without the need for specialised
openEHR validation tools. Although as openEHR experts we benefit from this
process, the advantages for those that are not is huge. 

 

The nice thing about using archetypes to define the schema of the target of
a transform is that you only need to write the transform template per
archetype once. Each message that uses the same input structure
corresponding to this archetype can reuse the same transform. Unfortunately,
the real world of integration is not so simple and different source systems,
even different messages from the same source system may be different, but
you still have a good starting point to tweak the transform to support the
variation between implementations. 

 

I hope this helps.

 

Regards

 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Chang, Wo L.
Sent: Saturday, 4 February 2012 8:07 AM
To: openehr-technical at openehr.org
Subject: Building software to convert HL7 v2/v3 messaging into archetypes &
templates

 

Dear All,

 

I hope this is the right reflector..

 

First of all, thanks to those who developed tools, prepared tutorials,
etc.!!

I have spending the last few days playing around with the followings:

. Java Reference Implementation of openEHR

. LiU-Archtype-Editor-0.5.2

. Archtype Editor 2.2.779

. ADL 1.5 Workbench beta

. Template Designer 2.6.1213.3

. Etc.

Along with reading very good tutorials on:

. Intro to openEHR, Sam Heard

. Knowledge-enabled approach to eHealth records, Heather Leslie

. Using Archtypes with HL7 Messages and Clinical Documents, Health
Frankel

. EN 13606-2 Gello - DCM, Andrew McIntyre

. Etc.

And openEHR stable specifications on:

. Introducing openEHR

. Architecture Overview

. Etc.

And ISO 13606 Part-1 and Part-2.

 

I truly believe the archtype/template would be the right approach for my
project on long-term management and preservation of EHRs.  The Java ref.
implementation libraries, Archtype Editor, Template Designer are great
utils/tools.

 

My basic question is: are there any public tools available to allow me to
covert HL7 v2/v3 messaging to/from archtypes/templates as described in
Health Frankel's tutorial on "Using Archtypes with HL7 Messages and Clinical
Documents"?

 

I know there is deep learning curve and would very much appreciated for any
pointers.

 

Thanks in advance for any help!

 

--Wo

 

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

Python / Django experience??

[Heath Frankel]

Hi Ian,
Interested in how you think RLUS can support a Knowledge service?
Heath
On 01/02/2012 2:21 AM, "Ian McNicoll" 
wrote:

> Hi Pablo,
>
> Your initial ideas on a possible service layer would be very
> interesting. I think we are starting to see a need to support cross
> repository service layer but possibly split between formally governed
> assets and those that are in early or experimental stages of
> development (as we envisage with CKI). The requirements for governed
> cross-repository assets will be rather more demanding.
>
> Have you seen this HL7/OMG proposal?
>
> http://hssp-rlus-normative.wikispaces.com/home
>
> Might be a useful start point.
>
> 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
> Director/Clinical Knowledge Editor openEHR Foundation
> www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> SCIMP Working Group, NHS Scotland
> BCS Primary Health Care  www.phcsg.org
>
>
>
> On 31 January 2012 15:27, pablo pazos  wrote:
> > Hi Ian, it would be nice to share a common API or service layer that both
> > groups can rely on, so we can make our tools compatible in some way.
> > I have an informal list of requirements that this tool should support,
> maybe
> > we can start sharing our requirements and see if we can agree on a common
> > interface (API/services).
> >
> >
> > --
> > 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: Tue, 31 Jan 2012 14:57:20 +
> >> Subject: Re: Python / Django experience??
> >
> >> To: openehr-technical at openehr.org
> >>
> >> Thanks Pablo,
> >>
> >> I will be interested to see how your app develops. We have a few
> >> Python volunteers so hope to have something visibly quite soon.
> >>
> >> 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
> >> Director/Clinical Knowledge Editor openEHR Foundation
> >>  www.openehr.org/knowledge
> >> Honorary Senior Research Associate, CHIME, UCL
> >> SCIMP Working Group, NHS Scotland
> >> BCS Primary Health Care  www.phcsg.org
> >>
> >>
> >>
> >> On 31 January 2012 14:45, pablo pazos  wrote:
> >> > Hi Ian, we are planning to work in this area but not with those
> >> > technologies, I think it will be PHP or Java/Groovy.
> >> >
> >> > What we want is just that: "a very lightly-governed
> >> > archetype collaboration,
> >> > simple review and discussion space to enable early communication
> between
> >> > possible archetype developers".
> >> >
> >> > Firstly for the openEHR-ES community, to engage doctors and nurses in
> >> > archetype development, and later to show how to use that knowledge in
> an
> >> > EHR
> >> > tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/).
> >> > Later
> >> > it could be a general use tool.
> >> >
> >> > This will be part of our tool
> >> >
> >> > chain:
> http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png
> >> > And it'll serve as a continuation for the students of our openEHR
> >> > course, to
> >> > embrace and don't lose the momentum after the course.
> >> >
> >> >
> >> > --
> >> > 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: Wed, 11 Jan 2012 11:10:57 +
> >> >> Subject: Python / Django experience??
> >> >> To: openehr-technical at openehr.org
> >> >
> >> >>
> >> >> Hi all,
> >> >>
> >> >> Would any of you with Python / Django experience be interested in
> >> >> helping with a small open-source project to establish a 'Clinical
> >> >> Knowledge Incubator' website under the auspices of the Foundation?
> The
> >> >> intention is to establish a very lightly-governed archetype
> >> >> collaboration, simple review and discussion space to enable early
> >> >> communication between possible archetype developers. This is not
> >> >> intended to compete with a more formally-governed repository such as
> >> >> CKM but to allow archetypes, requirements and specification documents
> >> >> to be shared and discussed prior to more formal governance and
> >> >> development processes kicking in.
> >> >>
> >> >> The site will be based on the open source Snowcloud Clinical
> Templates
> >> >> framework see clinicaltemplates.org.
> >> >>
> >> >> The work needing done to adapt this for openEHR is broadly ..

pass_through and implementation directives in general

[Heath Frankel]

Erik,
I suspect the only tools using this are the Ocean Template Designer in its
Operational Template XML output which extends the release 1.0.x AOM. This
is only the second time I have presented this proposal,  last time we had
this same discussion it got no traction.
The CKM uses the Ocean OPT to generate HTML documentation of templates and
uses the pass-through directive to collapse insignificant containers.

There are a couple applications that use the Ocean OPT extensions of the
AOM for GUI generation but not sure if the use this directive.

Our implementation simply uses views, but my suggestion that we may want to
extend the scope to all program directives seems to have been accepted.

XML uses processing_instructions, not sure we need to worry about length,
we haven't until now and it only needs to be specified once.
Heath
On 31/01/2012 9:45 PM, "Erik Sundvall"  wrote:

> Hi!
>
> Ok, if implementation experience says it is better to have separate
> sections for human readable annotations and machine-targeted "program
> directives" then I guess that is a good approach. Are there any tools that
> support this now?
>
> If going for an RDF-like URI based approach for "program directives" or
> "implementation_directives" then those serialization formats that aim for
> human readability (e.g. ADL and YAML) may want to use some kind of
> URI-prefixing-mechanism to make the directives shorter and more readable.
> (Similar approaches are used in XML (namespaces) and many
> RDF serialization formats.)
>
> I assume "program directives" will include both pass_through and more
> purely GUI-oriented directives. Will they contain everything
> annotation/directive-like that is intended to be machine processable and
> human language independent? Is that a correct and shared view of the
> purpose?
>
> Are both "annotations" and "program directives" supposed to be attributes
> of the class AUTHORED_RESOURCE? I don't find them in the current
> http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdfbut
>  I guess that might be a matter of time constraints - or are they going
> to be only a part of AOM/ADL itself? I just want to check what the future
> thoughts are.
>
> Is "program directives" the best name? "Annotations" is very a very
> generic and useful name, but that word is already taken for the human
> readable stuff. Could anything from the following list inspire somebody
> with a more native feel for English to come up with
> alternate name suggestions?
> - directives (shorter and more general than "program directives").
> - instructions
> - notes
> - meta...something
> - commands
> - processing...
> - triples
> - links
> - extensions
> - ...
>
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
>
>
> On Tue, Jan 31, 2012 at 00:07, Heath Frankel <
> heath.frankel at oceaninformatics.com> wrote:
>
>> Hi Erik,
>> No problem with your RDF approach but I agree with Thomas that the
>> purpuse of view directives. (or more generally,  program directives) is
>> very different from annotations. XML Schema separates these two concepts.
>> Ocean has reused annotations in the template designer for these kind of
>> directives for some time as well as the hard coded hide-on-form, and it is
>> from this experience that we have proposed this separate section.
>> Heath
>> On 31/01/2012 8:12 AM, "Erik Sundvall"  wrote:
>>
>>> Please rewind to
>>> http://www.openehr.org/mailarchives/openehr-technical/msg05530.html and
>>> the followup messages in that thread.
>>>
>>> Using an RDF like URI-based approach still seems to be an option. No
>>> registering hassle or new sections in adl, just alternate use of the
>>> existing annotation section.
>>>
>>> // Erik
>>>  Den 30 jan 2012 14:31 skrev "Thomas Beale" <
>>> thomas.beale at oceaninformatics.com>:
>>>
>>>>  On 30/01/2012 03:16, Heath Frankel wrote:
>>>>
>>>>  Hi Pablo,
>>>>
>>>> ** **
>>>>
>>>> If I understand correctly, the pass_through attribute is only for data
>>>> displaying on a screen (as you mention the use for data grouping or
>>>> collapsing). If that's right, I don't think that should be part of the
>>>> generic template structure, because templates are meant to represent other
>>>> elements than data views/GUI, like messages, reports, etc.
>>>>
>>>>

pass_through and implementation directives in general

[Heath Frankel]

Hi Thomas,

I think you're going too far with this controlled key and syntax approach.
The important thing at this point is we get a structure that we can start
using to get more experience with.  Although my proposal was a simple
property value bag, I think your idea of a triplet is good, but we should do
this using attributes rather than syntax.  So a directive type, an name/ID
and value attributes seems like a pretty powerful structure, its similar the
Claim class in an Identity Model for authorisation (claim type, right,
resource).

 

I think the majority of view directive use will be in templates at the local
level, but certainly some directives are likely at the jurisdictional level
(e.g. pass_through).  For this reason, I think that we should not restrict
the values to only controlled values, controlled values are only necessary
for shared use and it is these that certainly need to have a registry.
Erik's RDF suggestion seems like a reasonable approach to doing this rather
than openEHR inventing a new scheme.  We need to support innovation in this
area and hence allow local groups to use local directive
type/identifiers/values at will and when they have something to bring back
to the community somewhere to register and align their local directives with
shared directives.  A consumer should only need to process the directives it
is interested in, unless we provide something like a must-understand
attribute.

 

With regard to inheritance of directives, I think this needs to be based on
the directive type.  In some cases we will want an override, in others we
would want addition or constraint.  Not sure yet whether this needs to be
specified in the directive or not so that the compile can generate the
appropriate result or always have the complete set and leave the
responsibility to the consumer to interpret the set.

 

I don't think we need to make this too complicated at first, the main thing
is to get the containment structure right, we can always add attributes such
as must_understand and override mode to the directive class later. 

 

Regards

 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Monday, 30 January 2012 11:52 PM
To: openehr-technical at openehr.org
Subject: pass_through and implementation directives in general

 

On 30/01/2012 03:16, Heath Frankel wrote: 

Hi Pablo,

 

If I understand correctly, the pass_through attribute is only for data
displaying on a screen (as you mention the use for data grouping or
collapsing). If that's right, I don't think that should be part of the
generic template structure, because templates are meant to represent other
elements than data views/GUI, like messages, reports, etc.

 

No, that is not what I are saying.  I are saying it can be used for more
than display purposes such as data views, messages, reports etc.

 

As you mention " screen layout and binding are consistent with the XML
schema or class it will bind to" I feel maybe this is a little attached to
Oceans implementation, e.g. in our implementaition we don't have binding
with XML Schemas .

 

Ocean doesn't bind to XML schema either, I used this as an example of why
you may want to ensure your presentation view is consistent with a data view
derived from the same template artefact.

 

The use of the annotation-like structure for view directives allows us to
separate these kind of directives from true annotations and the data
definition itself whilst providing flexibility for specifying a set of
directives that we know of now but may improve on later such as
pass_through, add to in the future, and also use in local environments.  We
need to remember that templates where inteded for local use cases but are
now also becoming important at jurisdictional levels for shared use.


Heath,

the options for passthrough today (ADL/AOM 1.5) seem to be the following:

*   leave it where it is today, specified on C_COMPLEX_OBJECT
*   move it to be an annotation within the new annotations section of
ADL 1.5 archetypes, with a key such as 'view_directive'
*   create an entirely new section, structured the same (?) as the
annotations section, within the archetype for view / other directives

The potential problems with including a new view-directives section within
archetypes include:

*   it makes the archetype dependent on those directives. They would
need to be limited to universal directives, because most UI/presentation, as
well as other implementation directives are locally specific, and there can
clearly be more than one, for a given archetype.
*   we don't yet know what structure such a directives section should
really take

Potential benefits:

*   the section can be specified within the AOM & ADL docs, i.e. no new
specs required
*   making a new section in archetypes & templates means that we don't
nee

pass_through and implementation directives in general

[Heath Frankel]

Hi Erik,
No problem with your RDF approach but I agree with Thomas that the purpuse
of view directives. (or more generally,  program directives) is very
different from annotations. XML Schema separates these two concepts.
Ocean has reused annotations in the template designer for these kind of
directives for some time as well as the hard coded hide-on-form, and it is
from this experience that we have proposed this separate section.
Heath
On 31/01/2012 8:12 AM, "Erik Sundvall"  wrote:

> Please rewind to
> http://www.openehr.org/mailarchives/openehr-technical/msg05530.html and
> the followup messages in that thread.
>
> Using an RDF like URI-based approach still seems to be an option. No
> registering hassle or new sections in adl, just alternate use of the
> existing annotation section.
>
> // Erik
>  Den 30 jan 2012 14:31 skrev "Thomas Beale" <
> thomas.beale at oceaninformatics.com>:
>
>>  On 30/01/2012 03:16, Heath Frankel wrote:
>>
>>  Hi Pablo,
>>
>> ** **
>>
>> If I understand correctly, the pass_through attribute is only for data
>> displaying on a screen (as you mention the use for data grouping or
>> collapsing). If that's right, I don't think that should be part of the
>> generic template structure, because templates are meant to represent other
>> elements than data views/GUI, like messages, reports, etc.
>>
>> ** **
>>
>> No, that is not what I are saying.  I are saying it can be used for more
>> than display purposes such as data views, messages, reports etc.
>>
>> ** **
>>
>> As you mention " screen layout and binding are consistent with the XML
>> schema or class it will bind to" I feel maybe this is a little attached
>> to Oceans implementation, e.g. in our implementaition we don't have binding
>> with XML Schemas .
>>
>> ** **
>>
>> Ocean doesn?t bind to XML schema either, I used this as an example of why
>> you may want to ensure your presentation view is consistent with a data
>> view derived from the same template artefact.
>>
>> ** **
>>
>> The use of the annotation-like structure for view directives allows us to
>> separate these kind of directives from true annotations and the data
>> definition itself whilst providing flexibility for specifying a set of
>> directives that we know of now but may improve on later such as
>> pass_through, add to in the future, and also use in local environments.  We
>> need to remember that templates where inteded for local use cases but are
>> now also becoming important at jurisdictional levels for shared use.
>>
>>
>> Heath,
>>
>> the options for passthrough today (ADL/AOM 1.5) seem to be the following:
>>
>>- leave it where it is today, specified on C_COMPLEX_OBJECT
>>- move it to be an annotation within the new annotations section of
>>ADL 1.5 archetypes, with a key such as 'view_directive'
>>- create an entirely new section, structured the same (?) as the
>>annotations section, within the archetype for view / other directives
>>
>> The potential problems with including a new view-directives section
>> within archetypes include:
>>
>>- it makes the archetype dependent on those directives. They would
>>need to be limited to universal directives, because most UI/presentation,
>>as well as other implementation directives are locally specific, and there
>>can clearly be more than one, for a given archetype.
>>- we don't yet know what structure such a directives section should
>>really take
>>
>> Potential benefits:
>>
>>- the section can be specified within the AOM & ADL docs, i.e. no new
>>specs required
>> - making a new section in archetypes & templates means that we don't
>>need any new tools to process these directives - the main archetype
>>compiler would do it
>> - we could make it so that *applying more local directives was done
>>by defining correct inheritance rules for the implementation-directives
>>section* - i.e. use inheritance
>>
>> As I think about this, I am starting to be persuaded that continuing to
>> use inheritance to achieve local additions and overrides is a good thing -
>> it works for the rest of the archetype. If we commit to this path, the
>> remaining question is: is the current annotations section structure
>> sophisticated enough to contain implementation directives? An example of
>> the annotations section from a current test a

pass_through attribute in ADL 1.5

[Heath Frankel]

David,

Pass_through has no relevance to this emphasis concept in any way.  It has
been a means to collapse container attributes such as items when the
hierarchical structure inherited from the RM or Archetype is no longer
desired or relevant in a template perhaps because sibling items in a cluster
or multiplicity has been constrained.

 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of David Moner
Sent: Thursday, 26 January 2012 9:16 AM
To: For openEHR technical discussions
Subject: Re: pass_through attribute in ADL 1.5

 

 

2012/1/25 Thomas Beale 

Maybe another way of understanding this flag is as 'this node can be skipped
without loss of meaning'. I would be very interested to know if we should
make AQL queries sensitive to this flag. Has anyone thought about that?



In this sense I can see the reason for this attribute, since it can be
understood as part of the documentation of the clinical model. But
definitely it is not clearly described at the specs since there it seems to
be linked to the presentation template only.

I fact, there is a similar attribute in EN13606 ITEM class, but used in an
opposite sense. The attribute is "emphasis" and it is described as "A way of
denoting that the composer wished to mark this ITEM as being of particular
note (an unusual measurement value, an unexpected outcome, anything that
might be considered necessary to highlight to a future reader)."

I have never thought about this. I don't know if this kind of annotations
("this item is important or clinically relevant or not") better fits as part
of the RM or part of the AOM. In other words, if this marker is related to a
specific data instance or to a data item definition in an archetype.

Thoughts on this?



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

pass_through attribute in ADL 1.5

[Heath Frankel]

Hi Pablo,

 

If I understand correctly, the pass_through attribute is only for data
displaying on a screen (as you mention the use for data grouping or
collapsing). If that's right, I don't think that should be part of the
generic template structure, because templates are meant to represent other
elements than data views/GUI, like messages, reports, etc.

 

No, that is not what I are saying.  I are saying it can be used for more
than display purposes such as data views, messages, reports etc.

 

As you mention " screen layout and binding are consistent with the XML
schema or class it will bind to" I feel maybe this is a little attached to
Oceans implementation, e.g. in our implementaition we don't have binding
with XML Schemas .

 

Ocean doesn't bind to XML schema either, I used this as an example of why
you may want to ensure your presentation view is consistent with a data view
derived from the same template artefact.

 

The use of the annotation-like structure for view directives allows us to
separate these kind of directives from true annotations and the data
definition itself whilst providing flexibility for specifying a set of
directives that we know of now but may improve on later such as
pass_through, add to in the future, and also use in local environments.  We
need to remember that templates where intended for local use cases but are
now also becoming important at jurisdictional levels for shared use.

 

I don't believe that pass_through should be hard coded into the AOM.  It
should be in a more generic framework such as that I proposed in my previous
email.

 

Heath

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

pass_through attribute in ADL 1.5

[Heath Frankel]

Hi Pablo,

The Ocean Template Desiner is now freely available from
https://wiki.oceaninformatics.com/confluence/display/TTL/Template+Designer+R
eleases.

 

The pass_through view constraint is not a GUI directive, it is a data view
directive which is consistent with archetypes/templates being definitions of
data structures.  Just as form generators may use this data definition to
lay out a form and bind to a data instance, it may use this pass_through
view constraint to collapse a redundant grouping on a screen.  Similarly an
XML schema or class  generator may use this same constraint to collapse a
redundant element grouping.  This ensures that screen layout and binding are
consistent with the XML schema or class it will bind to.

 

I historically was of the opinion that GUI only directives such as control
type or position should be provided separately as these a really
implementation specific and have minimal use in shared artefacts such as
archetypes and templates. Having said that the view constraint could easily
be used for this purpose if desired.

 

The XSD for the view constraint is as follows:

 



  



  



  



  



  

  



  





  



  



 

An example use of this is as follows:

 

http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns="http://schemas.openehr.org/v1";>

.

  



  

true

  



  



 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Thursday, 12 January 2012 9:24 AM
To: openehr technical
Subject: RE: pass_through attribute in ADL 1.5

 

Hi Heath,

Hi Paplo,

Your suggestion here is too oriented to GUI uses cases. As Tom indicated,
pass_through is intended to support other data oriented contexts such as
flattening schema and class hierarchies, this is why is was generalised from
hide-on-form as used in the template designer.

In that case, I think we should separate the uses of the directive. IMO is a
little anoying to use the same directive to do semantic processing of the
structure and to do GUI generation/customization.



If you look at the Operational Template exported in the Template Designer
there is an AOM extension of view-constraints which structurally are the
same as annotations where there is a hash of paths of hash of constraint
name. This supports the pass_through constraint and any other constraints of
this class. 

I'm afraid I could not see what you mention, I don't have a licence for the
TD.



The term view was adopted because it is used in both GUI and data oriented
contexts.

I can provide the XML schema for this AOM extension used by the template
designer if people are interested.

It would be nice to see the schema and some documentation about the
structure and rationale behind it if you have some (just to understand the
XML structure).

Cheers,
Pablo.

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

Constraints on class methods

[Heath Frankel]

Further to my previous email, I believe the original intent of the name
attribute is a form caption of an element value,  the approach of adding a
numeric suffix to provide a unique key is contrary to this original intent.
Btw, another example of multiple names values conflict with this unique
name rule is multiple alias party-identity occurences, in fact anywhere
where you use a coded name such as a lab observation with multiple
occurrences.  Adding a suffix makes the value different to the code rubric,
which frowned upon in terminology circles.

Heath
On 11/01/2012 11:25 PM, "Heath Frankel" 
wrote:

> Peter,
> I believe this unique name rule should be reviewed and revoked. It is not
> formally defined, as indicated in your referenced Jira issue its only
> stated in the architecture overview in the context of paths which assumes
> name is the unique within a container. I have other examples where it is
> desirable to get multiple items with the same node-id but not the entire
> set and name is the obvious collector. It also causes issues in renamed
> templated items which you still want to allow more than one occurrence of
> that item.
> I believe that path predicates are context specific, some times you may
> want to use event time or entry uid for example, and should not be dictated
> by the reference model.
> Heath
> On 10/01/2012 10:43 PM, "Peter Gummer" 
> wrote:
>
>> Sebastian Garde wrote:
>>
>> > A few other functional properties come to mind such as "type" in
>> PARTY_RELATIONSHIP ...
>> > Re "type": This is the same as the property "name" (because of the
>> type_validity invariant)
>>
>> Yes, funny you should mention that, Sebastian, because I discovered
>> yesterday that this is a bug in the spec. As is well known, the "name" must
>> be unique among siblings within a container. This uniqueness is
>> incompatible with the PARTY_RELATIONSHIP "type", because it would be common
>> for a party to have multiple relationships of the same type.
>>
>> http://www.openehr.org/issues/browse/SPECPR-54 discusses this. I had to
>> find a work around for it in my software. I chose to violate the
>> type_validity invariant: when setting the type, I append a sequential
>> number to it to set the name; and I compute the type by stripping the
>> sequential number off the name. This ensures that the name is unique, while
>> permitting multiple siblings of the same type.
>>
>> - Peter
>> ___
>> 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/20120112/4674a530/attachment.html>

Constraints on class methods

[Heath Frankel]

Peter,
I believe this unique name rule should be reviewed and revoked. It is not
formally defined, as indicated in your referenced Jira issue its only
stated in the architecture overview in the context of paths which assumes
name is the unique within a container. I have other examples where it is
desirable to get multiple items with the same node-id but not the entire
set and name is the obvious collector. It also causes issues in renamed
templated items which you still want to allow more than one occurrence of
that item.
I believe that path predicates are context specific, some times you may
want to use event time or entry uid for example, and should not be dictated
by the reference model.
Heath
On 10/01/2012 10:43 PM, "Peter Gummer" 
wrote:

> Sebastian Garde wrote:
>
> > A few other functional properties come to mind such as "type" in
> PARTY_RELATIONSHIP ...
> > Re "type": This is the same as the property "name" (because of the
> type_validity invariant)
>
> Yes, funny you should mention that, Sebastian, because I discovered
> yesterday that this is a bug in the spec. As is well known, the "name" must
> be unique among siblings within a container. This uniqueness is
> incompatible with the PARTY_RELATIONSHIP "type", because it would be common
> for a party to have multiple relationships of the same type.
>
> http://www.openehr.org/issues/browse/SPECPR-54 discusses this. I had to
> find a work around for it in my software. I chose to violate the
> type_validity invariant: when setting the type, I append a sequential
> number to it to set the name; and I compute the type by stripping the
> sequential number off the name. This ensures that the name is unique, while
> permitting multiple siblings of the same type.
>
> - Peter
> ___
> 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: 

Carriage returns in DV_TEXT not allowed

[Heath Frankel]

We currently ignore this constraint as most multi line cases don't need the
complexity of dv-text and the parsing overhead to get a list of dv-text is
significant, and as you say we don't have a container of dv-paragraph
unless you use multiple elements which is a heavy solution.
I don't think dv-docunent is the right term to use considering the
correlation between composition and document in cda-openEHR mappings. We
have talk in the past about an element supporting a list of values, e.g.
dv-list, otherwise another glyph grouping term should be used.
Having said that, there certainly are issues with using new lines in
dv-text, in particular which new line character sequence scheme to use but
also how these are represented in XML, as literal characters or emcoded.
Finally there is an issue when applying xslt to these new line
representations, we currently need to support all possibilities. Using
dv-paragraph would make it explicit but has overhead and issues described
above.
I think we need to support new lines in dv-text for simple scenarios but we
need normalized guidance on XML representation, while ensuring we can
properly support dv-paragraph for more complex situations in future.

Heath
On 10/01/2012 11:49 PM, "Thomas Beale" 
wrote:

>  On 10/01/2012 10:05, Leonardo Moretti wrote:
>
> If DV_TEXT doesn't allow to use carriage returns, line feeds, or other
> non-printing characters, as stated in
> http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf,
> pag 29, there is a way to represent short text with minimal formatting
> characters (carriage returns)? Which data type should be used?
>
>
> It would be interesting to know how many other implementers agree with
> this restriction. It was put in (from memory) in the very early days of
> modelling, based on GEHR, and possibly somewhat on 13606 - nearly 10 years
> ago!
>
> The idea was that DV_TEXT models a 'text fragment', essentially the idea
> of a word, string of words, sentence or possibly a group of sentences. No
> CR/LF were allowed because this is taken as a paragraph delimiter, and the
> type DV_PARAGRAPH was defined to represent multiple DV_TEXTs making up a
> long tract of text like a report. In proper word processing & publishing,
> this is correct; a 'paragraph' has no CR/LF in it, which is what allows
> resizing to work properly in different screen / form widths.
>
> Additionally, any 'atomic' text item, e.g. a single disease name, single
> sentence etc - which make up the majority of text data within structured
> data - should not have a CR/LF.
>
> This way of thinking may be dated, and it is a good question as to when a
> piece of text can't be a single DV_TEXT. If we stick with the current
> model(and
>  remember, a DV_CODED_TEXT is-a DV_TEXT in openEHR), the openEHR RM is
> imposing a simple word processing model of 'paragraphs' made up of 'text
> fragments'. An alternative would be to allow anything in a DV_TEXT. The
> decision about when you have to have a new DV_TEXT is made on the basis of
> attributes other than the actual string value, i.e.:
>
>- hyperlink: if there is a hyperink, it applies to the entire DV_TEXT;
>therefore, if you only want a link to correspond to 2 words, then those 2
>words = 1 DV_TEXT
>- formattting: simple formatting like bolding, emphasis (about the
>same level as typical wiki markup) applies to the whole DV_TEXT;
> - mappings: coded mappings, e.g. ICD code applies to whole DV_TEXT;
>need to use multiple DV_TEXTs if only some words are to have an associated
>code mapping
>- formal coding: if a DV_CODED_TEXT is to be used - i.e. when the
>string value is the term for the code from its terminology (not just some
>mapping), then the DV_CODED_TEXT.value can only consist of the exact word
>string to which the code corresponds; more DV_TEXTs have to be added using
>a DV_PARAGRAPH to construct a whole paragraph
>
> The best approach with the current model is:
>
>- for atomic text items, e.g. single word/sentence answers to
>questions, single coded terms like names of diseases, procedures etc, use a
>single DV_CODED_TEXT or DV_TEXT.
>- for a tract of text containing some words that are hyperlinked /
>coded / formatted, use a DV_PARAGRAPH containing multiple DV_TEXTs.
>- Or else you use a DV_PARSABLE, containing XML, HTML, RTF or whatever
>you like - but ... no guarantee the receiver can read it!
>
> This does not actually solve properly the problem of how CR/LFs are added.
> If we assume one DV_PARAGRAPH = 1 CR/LF (as in word processing) then a
> report needs to consist of multiple DV_PARAGRAPHs, and we don't currently
> have a data type for that. To fix the current model we could add a new type
> DV_DOCUMENT, which contains multiple DV_PARAGRAPHs. Or we could remove the
> restriction on CR/LF on DV_TEXT, but that then w

pass_through attribute in ADL 1.5

[Heath Frankel]

Hi Paplo,
Your suggestion here is too oriented to GUI uses cases. As Tom indicated,
pass_through is intended to support other data oriented contexts such as
flattening schema and class hierarchies, this is why is was generalised
from hide-on-form as used in the template designer.
If you look at the Operational Template exported in the Template Designer
there is an AOM extension of view-constraints which structurally are the
same as annotations where there is a hash of paths of hash of constraint
name. This supports the pass_through constraint and any other constraints
of this class.
The term view was adopted because it is used in both GUI and data oriented
contexts.
I can provide the XML schema for this AOM extension used by the template
designer if people are interested.
Heath
On 10/01/2012 11:47 AM, "pablo pazos"  wrote:

>  Hi Diego & Thomas,
>
> I think this should be out of the scope of the new semantic/structural
> archetypes & templates specs, and should be included in a new specification
> of GUI Templates.
>
> I been working on this subject for a while and want to formalize a XML
> format to have GUI directives / GUI definition (input controls, position,
> visibility, order, ...) and binding with structural archetypes and
> templates (in a system this bindings should be to OPTs).
>
>
> http://www.openehr.org/wiki/display/impl/GUI+directives+for+visualization+templates
>
>
> On february/march 2012 I'll be working on this to improve the flexibility
> of our current templates:
> http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen%2Ftemplates%2Fhce
>
>
> If anyone want to work on this, would be a pleasure to colaborate.
>
> FYI: We have developed a prototype editor for those GUI templates:
> http://code.google.com/p/template-editor-open-ehr-gen/
> It is web based, and can access archetypes repositories via HTTP to pull
> archetypes to be included in a GUI template.
>
> --
> 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, 9 Jan 2012 19:03:32 +
> From: thomas.beale at oceaninformatics.com
> To: openehr-technical at openehr.org
> Subject: Re: pass_through attribute in ADL 1.5
>
> On 05/01/2012 08:54, Diego Bosc? wrote:
>
> Put a couple of comments on the wiki, but I think it is a thing that
> should be discussed on the list.
> In ADL 1.5 a flag 'pass_through'  was added. Its definition is 'Allows
> nodes required for structuring data but otherwise redundant for screen
> display and reporting to be detected by rendering software'. So now we
> have a GUI directive on the ADL. Shouldn't this be a part of the
> reference model information (if it is never supposed to be displayed)
> or part of a 'visualization template' (another different level).
> I would say that more information about visualization will be needed,
> and having visualization information separated between two different
> places feels like a bad design move.
>
>
> In general I am inclined to agree, and I have to say I have been in two
> minds about having this attribute in there. I am convinced by clinical
> modellers who say that something is needed to control interior tree nodes
> not appearing on the GUI (indeed, it is visual pollution). And - even if
> the template were being used to build a message definition (generated XSD
> or similar), and the data were processed into some report or other output,
> this attribute would be respected (technically, this is still 'user
> interface').
>
> I know the passthrough attribute is used often from the current .oet
> template usage, so we need a way of dealing with the requirement. If we
> take it out, and say it is a GUI directive, the problem is we currently
> have no formal framework for that yet. Maybe the lesser of two evils is to
> do what Koray (I think?) said, and make it a special kind of annotation. I
> have implemented annotations in ADL/AOM 1.5, and they work nicely. We need
> to agree on some kind of standard representation, e.g.
>
> ___
> 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: 

Did anybody implement AQL with a LL parser framework?

[Heath Frankel]

Hi Seref and Erik,
The grammar published on openEHR by Ocean Informatics was what we used with
a proprietary third party tool. If people have converted the grammar to
work with more standard parsing tools and want to post it to the AQL wiki
page for others to use then we too can test it with our tool and if
successful can deprecate the original.

Heath
On 05/01/2012 9:31 PM, "Seref Arikan" 
wrote:

> Thanks Erik,
> AntlrWorks is nice, but it has a problem of slowing down for some reason,
> even if the grammar is not that big. Appears to be a known issue, but the
> latest version still has this behaviour. Still beats anything else out
> there though.
>
> For me, ANTLR's main advantage is its infrastructure to support multiple
> target languages. I've used JavaCC a long time ago, and I don't think it is
> inferior to Antlr, though Antlr has a bit of a learning curve.
>
> I'm working on the refactoring of the existing grammar via elimination of
> left recursions, but my point is pretty much the same with yours; moving
> grammars to Antlr would help different groups develop parsers/tools easier.
> I've asked the original question to see if people did the actual work of
> eliminating recursions and basically making grammar LL compatible, and
> based on the responses I can see that they have.
>
> This is good news, since it means we may be able to build a community
> around Antlr based implementations.  Good to hear that you'll be putting
> something out soon, I'll try to do the same ;)
>
> Regards
> Seref
>
>
> On Thu, Jan 5, 2012 at 10:12 AM, Erik Sundvall wrote:
>
>> Hi!
>>
>> We implemented an AQL parser using JavaCC. My colleague Mikael Nystr?m
>> made some transformations to make the published AQL grammar work in JavaCC.
>> Mikael is on vacation right now, but I'm sure he does not mind sharing his
>> experiences once he gets back.
>>
>> I do think it would be interesting to switch to ANTLR sooner or later in
>> order to share efforts between projects with different
>> implementation/target-languages and because the ANTLRWorks environment
>> http://www.antlr.org/works/index.html looks promising compared to the
>> pretty bad JavaCC-plugin in e.g. Eclipse.
>>
>> Our parser (and thus also the modified grammar) will soon be open sourced
>> so you are free to use it. So if you are not in an extreme hurry I'd
>> suggest using or getting inspiration from what we have already done.
>>
>> Best regards,
>> Erik Sundvall
>> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
>>
>>
>>
>> On Wed, Jan 4, 2012 at 16:37, Seref Arikan <
>> serefarikan at kurumsalteknoloji.com> wrote:
>>
>>> Greetings,
>>> The AQL grammar from the wiki has direct and indirect left recursion.
>>> Which means without changes in the grammar, LL parser generators (both
>>> JavaCC and Anltr) can't generate parsers for this grammar.
>>>
>>> I'm curious if anybody has refactored this grammar for LL parser
>>> generators. Shinji? Your latest release includes an AQL parser does not it?
>>> Could you please share your method? I can always look at the code, but
>>> you'd probably save me time :)
>>>
>>> I'm interested in experiences of others too.
>>>
>>>
>>> Kind regards
>>> Seref
>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

How is assumed value marked on domain types? (in XML)

[Heath Frankel]

Diego,
What tool are you using to generate your AOM XML?
The tool issue tracker may be a more appropriate place for these tooling
issues.
Heath
On 05/01/2012 10:34 PM, "Diego Bosc?"  wrote:

> In ADL, the assumed value of a domain type is marked like this:
>
> defining_code matches {
>[local::
>at1000, -- Standing
>at1001, -- Sitting
>at1002, -- Reclining
>at1003, -- Lying
>at1014; -- Lying with tilt to left
>at1001] -- assumed value
> }
>
> but in the xml form, the assumed value is missing. The schema does not
> reflect this (I know it is outdated)
>
>
> 
>CODE_PHRASE
>
>  true
>  true
>  false
>  false
>  0
>  1
>
>at0009
>
>  local
>
>at1000
>at1001
>at1002
>at1003
>at1014
>  
>
> Can we reach a quick consensus on how should this be stated? Can we
> use an  label as in all other types?
> ___
> 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: 

Basetypes (schema/specification)

[Heath Frankel]

What is the issue?  The upper case types defined in the logical
specifications, whilst the CamelCase are ITS defined.  Like many mappings
from logical specifications to an implementation technology, the XSD is not
a pure representation of the logical specification. At least using this
mixed approach it is obvious which are which.  

If you are concerned about this because you are generating classes from the
schema, then this is the price you pay unfortunately.  It is impossible to
represent the logical specifications in its entirety using XSD, however it
does provide you with a pretty good serialised representation of the
specified models, these types do not appear in XML instances.

Having said that, it is likely that the XML schema will be reviewed in the
near future as part of ADL 1.5 release and we are considering the pros and
cons of various XSD representations based on human readability,
specification alignment, class generation etc. You may want to contribute to
this when it gets underway.

Heath 

-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Diego Bosc?
Sent: Wednesday, 21 December 2011 7:00 PM
To: For openEHR technical discussions
Subject: Re: Basetypes (schema/specification)

ok, then the link of the XSD is pointing to an old version (link on this
page
http://www.openehr.org/svn/specification/TRUNK/publishing/its/XML-schema/ind
ex.html).
This is the page that can be reached through the openEHR website menu.
and the second issue is still true: types with CamelCase and underscores
names exist on the same schema

2011/12/21 Heath Frankel :
> http://svn.openehr.org/specification/TAGS/Release-1.0.2/ITS/XML-schema 
> is the latest schema.
>
> If anything the documentation may be out of sync. ?The documentation 
> is generate using Oxygen.
>
> Heath
>
> -Original Message-
> From: openehr-technical-bounces at openehr.org
> [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Diego 
> Bosc?
> Sent: Wednesday, 21 December 2011 4:08 AM
> To: For openEHR technical discussions
> Subject: Basetypes (schema/specification)
>
> I have been doing some tests with the file archetype.xsd available on 
> the webpage and I have run with some problems.
> The main one is regarding BaseTypes.xsd, which supposedly defines 
> types such as intervalOfInteger, intervalOfDate..., but doesn't contain
them.
> Documentation
> (http://www.openehr.org/svn/specification/TRUNK/publishing/its/XML-sch
> ema/do
> cumentation/BaseTypes.xsd.html#h888547087)
> says otherwise, so I'm not sure how are documentation and schema 
> generated/related.
>
> I suspect that schema is out of date, but I don't quite understand how 
> a supposedly autogenerated documentation and his XSD disagree. I know 
> that this kind of approach is being left behind, but at least a 
> version public on the webpage should be complete (take note that I'm 
> not talking about being correct regarding the specifications, for the 
> moment I just want to compile
> it)
>
> Another thing I have detected is a mix of CamelCase and underscores on 
> the types definition of current BaseTypes.xsd. There are things like 
> DATA_VALUE or DV_DATE_TIME but also archetypeNodeId, atCode, or
Iso8601DateTime.
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

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

Basetypes (schema/specification)

[Heath Frankel]

http://svn.openehr.org/specification/TAGS/Release-1.0.2/ITS/XML-schema is
the latest schema.

If anything the documentation may be out of sync.  The documentation is
generate using Oxygen.

Heath

-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Diego Bosc?
Sent: Wednesday, 21 December 2011 4:08 AM
To: For openEHR technical discussions
Subject: Basetypes (schema/specification)

I have been doing some tests with the file archetype.xsd available on the
webpage and I have run with some problems.
The main one is regarding BaseTypes.xsd, which supposedly defines types such
as intervalOfInteger, intervalOfDate..., but doesn't contain them.
Documentation
(http://www.openehr.org/svn/specification/TRUNK/publishing/its/XML-schema/do
cumentation/BaseTypes.xsd.html#h888547087)
says otherwise, so I'm not sure how are documentation and schema
generated/related.

I suspect that schema is out of date, but I don't quite understand how a
supposedly autogenerated documentation and his XSD disagree. I know that
this kind of approach is being left behind, but at least a version public on
the webpage should be complete (take note that I'm not talking about being
correct regarding the specifications, for the moment I just want to compile
it)

Another thing I have detected is a mix of CamelCase and underscores on the
types definition of current BaseTypes.xsd. There are things like DATA_VALUE
or DV_DATE_TIME but also archetypeNodeId, atCode, or Iso8601DateTime.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Questions about the relationship between Instruction, workflow and Action

[Heath Frankel]

Perhaps I responded to the wrong thread, I will repost what I said in
response to "Revision of Instructions - clinical implications".

 

When you order a lab test you actually need an Instruction to define the lab
test, and an action to put It into the ordered state.  The request time of
the lab test order is the time in the action with the ordered state.  An
instruction without an action is not yet executing within a workflow. 

 

BTW, the workflow definition attribute is not intended to carry archetyped
data.  It is intended to specify the definition of a workflow executing
within a workflow engine or similar.  The workflow ID references the
instance of the workflow executing for this instruction.  We also use this
for real world non-computerised workflows, such as a lab order number to
allow us to keep track all the entries that relate to the same lab request
including observations and evaluation.

 

Heath

 

From: Heather Leslie [mailto:heather.les...@oceaninformatics.com] 
Sent: Monday, 12 December 2011 1:30 PM
To: 'For openEHR technical discussions'
Cc: heath.frankel at oceaninformatics.com
Subject: RE: Questions about the relationship between Instruction, workflow
and Action

 

 

 

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

 

Hi Heather,

I asked Heather on that issue (
<http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-ar
chetype/>
http://omowizard.wordpress.com/2011/07/11/anatomy-of-an-procedure-action-arc
hetype/) and her answer seems reasonable too: generaly scheduling tasks are
done on external administrative systems (LIS, RIS, ...) and them a message
is sent to the EHR to tell the Instruction had been scheduled.

 

But: how is that change of the Instruction state recorded on the EHR?

[HL>] The INSTRUCTION for a procedure remains unchanged, unless the
clinician changes the nature of the original order and this is carried out
with a revision of the committed INSTRUCTION.

 

The ACTION is recording the progress of activity in carrying out the
INSTRUCTION - ie the procedure is planned, scheduled, performed, completed
and at each of these pathway steps the appropriate data is captured eg what
procedure is scheduled and the scheduled time; and what/ when was actually
finally performed etc. What was actually done/performed/administered may be
different to what was originally ordered due to clinical circumstances etc -
the ACTION allows this evolution to be captured. Yet through all this the
original instruction/order persists as is.

 

I understood that part and agree 100%: We have the record of the original
Instruction untouched, or if it need a change from a clinical point of view,
this will be a new version/revision of the previous Instruction.

 

Receiving a message from an external system could trigger the creation of an
ACTION?

 

[HL>] It could trigger the creation of an ACTION if received from a
scheduling system and there had been no ACTION created previously. That same
newly created ACTION could then be used to record the data against
subsequent pathway steps.

OR the message could be used to trigger an entry using the  existing ACTION
containing the Scheduled data against the Scheduled pathway.

 

That's the problematic point I see on the use of an ACTION to record
something that is merely administrative and may have no clinical relevancy.

[HL>] From my point of view, it may be an administrative detail, but just
the fact that something has been scheduled (without necessarily details of
the time/date/location) is a valuable part of a clinical record. It does
have clinical relevance as it records what has been done in the steps
required to carry out at order/INSTRUCTION. While a non-clinical person may
have technically carried out the ACTION, it is still critical info in the
clinical record, still a 'clinical action' IMO.

An ACTION should be ... "Used to record a clinical action that has been
performed, which may have been ad hoc, or due to the execution  of an
Activity in an Instruction workflow. Every Action corresponds to a careflow
step of some kind or another."
(http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_im.pdf page 73).

 

I think we could analize this topic through an implementation (I think
that's what you and Sam have mentioned) with the solution of having messages
triggering ACTION creation or recording data on existing ACTIONs.

[HL>] It is not at all simple to envisage how the flow of INSTRUCTION and
various resulting ACTIONS play out, and I can't pretend to have it all 100%
clear, but with implementations (and Heath Frankel certainly has plenty of
recent experience) it is proving to work in practice.

 

But I think we need to 

Could YAML replace dADL as human readable AOM serialization format?

[Heath Frankel]

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

Could YAML replace dADL as human readable AOM serialization format?

[Heath Frankel]

Thanks Erik,

Interesting to see the line up.  Can't believe that XML wasn't the longest
file in the list, that kills one of the arguments for JSON vs XML.

 

For someone that is not aware of YAML, are the white space significant.  If
so, this kinds of kills it for me, otherwise for a Human reader its fairly
natural to read without lots of brackets of various kinds.

 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall
Sent: Friday, 2 December 2011 8:07 AM
To: For openEHR technical discussions
Subject: Re: Could YAML replace dADL as human readable AOM serialization
format?

 

Hi!

 

Let the battle begin :-) see:

http://www.imt.liu.se/~erisu/2011/AOM-beauty-contest.html

 

On Tue, Nov 22, 2011 at 13:24, Thomas Beale
 wrote:

actually, ADL 2.0 as reported in this document is now obsolete. The ADL 1.5
compiler already does this, and will use it as a fast save/retrieve format.

 

Will cADL become optional or go away somehow?

 

One area where dADL beats JSON and YAML (I think) is its better support for
Xpath-like paths.

 

Why would that be different? I guess most path queries will run on
instantiated object trees rather than on documents and then there is no
difference - and if paths were run directly on documents, then please
explain why dADL would support them better.

 

Plus its much more compact than JSON. 

 

Much? Less noisy I would agree to though.

 

Personally I find YAML hard to read because there are so many syntax
elements (triple '-', triple '.' etc) but that might just be me.

 

Have a look at...

http://www.imt.liu.se/~erisu/2011/AOM-beauty-contest.html

...again.

 

The triple '-' and triple '.' are (mostly optional) start and end markers of
documents that make life easier when concatenating streams/documents, see
the YAML specification.

 

Am I the only one that thinks YAML is more readable than dADL?

 

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

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

occurrences and cardinality in ADL, XML, JSON

[Heath Frankel]

Hi Thomas,

 

yes - everyone goes through the same process I think. The P_ classes I now
have in the ADL 1.5 compiler are my latest addition in this process.



[HKF: ] No, this is something you learn as it sounds like both you, I and
others do doubt have learned.  The first thing a new comer does is use their
favourite XML toolkit to create classes and instances derived from the XML
Schema.  This is why we still get questions about the slight variations that
we currently between the schema and the specifications.



The thing is, we do want to reduce the entry point to use openEHR and if we
require a custom serializer then we make this entry point harder. 


well, not if all the tooling is done and easy to use. Who writes their
own XML parser these days?

[HKF: ] Wasn't talking about that.  However, actually we do, they are
SAX-based readers where we want a stream reader into a domain model rather
than an XML DOM.

As I have stated previously, even with existing tools out there such as the
Eiffel, Java, Python, Ruby and C# open source projects, people will still
write their own for whatever reason.  I bet there are at least a dozen Java
RM implementations in the world, I know of four. 

Heath

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