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.

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=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=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 updating this part rece

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=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=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 which the 

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

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

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


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

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" 
<i...@freshehr.com<mailto:i...@freshehr.com>> wrote:

Thanks Heath,

That makes sense. Does OceanEHR validate the constraint?

Ian

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

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

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

Regards

Heath

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



Hi Koray,

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

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

Ian

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

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

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

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

An example ADL:

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

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

Cheers,

-koray


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




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

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

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 >
Sent: Sunday, February 14, 2016 5:10 AM
Subject: Re: Strange use of 'offset' as a settable RM attribute
To: For openEHR technical discussions 
>


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=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 
> 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=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 
> 
wrote:
On 28 Nov 2015, at 00:36, Ivar Yrke > 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. 

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 
> 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=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 
> 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 rsk fctr

XadAN

NIPE hip, no abnor 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]

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


2015-10-08 1:23 GMT+02:00 Heather Leslie 
>:
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 
>;
 For openEHR clinical discussions 
>
Cc: For openEHR implementation discussions 
>
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 ° 

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 
i...@freshehr.commailto: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.commailto:i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.orgmailto: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? 
yamp...@gmail.commailto: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 
i...@freshehr.commailto: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 7859tel:%2B44%20%280%29775%20209%207859
office +44 (0)1536 414994tel:%2B44%20%280%291536%20414994
skype: ianmcnicoll
email: i...@freshehr.commailto:i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.orgmailto: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, ??? 
edwin_ue...@163.commailto:edwin_ue...@163.com wrote:
dear all ,
how could i  explain to someone difference and relationship between openEHR 
and EN13606
thx
--
???
15901958021



???1?http://r.mail.163.com/r.jsp?url=http%3A%2F%2F1.163.com%2Fhd%2Foneact%2Fhdframe.do%3Fid%3D21%26from%3Dfooter_beautysign=817593681_r_ignore_statId=7_13_79_48_r_ignore_uid=n...@163.com

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


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


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

___
openEHR-technical mailing list

Re: VERSION.lifecycle_state options

[Heath Frankel]

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


--
Sebastian Iancu
mob: +31625588176tel:%2B31625588176 | email: 
sebast...@code24.nlmailto:sebast...@code24.nl | skype: sebastian_iancu
Code24 B.V.
Comeniusstraat 5, 1817MS Alkmaar, The Netherlands
www.code24.nlhttp://www.code24.nl


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

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



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



--
Sebastian Iancu
mob: +31625588176tel:%2B31625588176 | email: 
sebast...@code24.nlmailto:sebast...@code24.nl | skype: sebastian_iancu
Code24 B.V.
Comeniusstraat 5, 1817MS Alkmaar, The Netherlands
www.code24.nlhttp://www.code24.nl

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

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
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 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
 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 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.commailto:pazospablo at 
hotmail.com pazospablo at hotmail.commailto: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.orgmailto: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 4tel:2015-04-07%204:06 GMT+02:00 pazospablo at 
hotmail.commailto:pazospablo at hotmail.com pazospablo at 
hotmail.commailto: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.orgmailto:openEHR-clinical at 
lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.orghttp://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.orgmailto:openEHR-clinical at 
lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150407/ad54da7d/attachment.html

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 damoca at gmail.commailto: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.commailto:pazospablo at 
hotmail.com pazospablo at hotmail.commailto: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.orgmailto: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 4tel:2015-04-07%204:06 GMT+02:00 pazospablo at 
hotmail.commailto:pazospablo at hotmail.com pazospablo at 
hotmail.commailto: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.orgmailto:openEHR-clinical at 
lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.orghttp://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.orgmailto:openEHR-clinical at 
lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150407/2e90d000/attachment-0001.html

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

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? yampeku at gmail.com 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 serefarikan at 
 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 bert.verhees at rosa.nl 
 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 bert.verhees at rosa.nl 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
 peter.gummer at oceaninformatics.com 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).
 Please inform us immediately if you are not the addressee.
 
 
 --
 This e-mail message is intended exclusively for the addressee(s).
 Please inform us immediately if you are not the addressee.
 
 
 ___
 

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 thomas.beale at 
oceaninformatics.commailto: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 thomas.beale at 
oceaninformatics.commailto: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.orgmailto:openEHR-technical at 
lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150120/38f42ffa/attachment-0001.html

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 Bostjan.Lah at marand.si 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 sebastian at code24.nl 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 querying statements. Although you can differentiate the 
 draft from published archetypes in the archetypes themselves, 

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 pazospa...@hotmail.com
To: openeh technical openehr-technical at lists.openehr.org
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.comhttp://cabolabs.com/es/homehttp://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

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 pazospa...@hotmail.com
To: openeh technical openehr-technical at lists.openehr.org
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.comhttp://cabolabs.com/es/homehttp://twitter.com/ppazos
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140907/fde4523a/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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140820/d5271530/attachment.html

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:

 

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

  eventConstraint

allowedTypePointInTime/allowedType

  /eventConstraint

/Rule

 

Shouldn't PointInTime be POINT_EVENT?

 

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

 

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

 

Thanks!


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

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

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 heath.frankel at oceaninformatics.com:
 Hi Pablo,

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



 Heath



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



 Hi all,



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



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



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

   eventConstraint

 allowedTypePointInTime/allowedType

   /eventConstraint

 /Rule



 Shouldn't PointInTime be POINT_EVENT?



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



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



 Thanks!


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


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

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 thomas.beale at oceaninformatics.com 
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:
iedfciga.png
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 
http://www.openehr.org/wiki/display/spec/ACTIVITY+Timing+in+Instructions . 
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 

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
 athanasios.anastasiou@**plymouth.ac.ukathanasios.anastasiou at 
 plymouth.ac.uk
 mailto:athanasios.anastasiou@**plymouth.ac.ukathanasios.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.__open**ehr.org http://openehr.org
 mailto:openEHR-technical@**lists.openehr.orgopenEHR-technical at 
 lists.openehr.org
 
 http://lists.openehr.org/__**mailman/listinfo/openehr-__**
 technical_lists.openehr.orghttp://lists.openehr.org/__mailman/listinfo/openehr-__technical_lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 


 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

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.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://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/20130702/d5190373/attachment.html

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 thomas.beale at oceaninformatics.com
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.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://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/20130418/939832e0/attachment.html

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 erik.sundvall at liu.se wrote:

 Ooops, accidentally sent unfinished mail... see additions below.

 On Wed, Jan 30, 2013 at 9:07 AM, Erik Sundvall erik.sundvall at liu.sewrote:

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

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 thomas.beale at oceaninformatics.com
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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130130/aa62590d/attachment.html

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 bert.verhees at rosa.nl 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.htmlhttp://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.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://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,
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 bert.verhees at rosa.nl 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.htmlhttp://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.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr

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 serefarikan at kurumsalteknoloji.com
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 bert.verhees at rosa.nl 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.htmlhttp://www.herongyang.com/XML-Schema

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:
oe:items xs:type=oe:ITEM_TREE xmlns:oe=... xmlns:xs=...
archetype_node_id=..oe:items

Heath
On Nov 28, 2012 9:07 AM, Bert Verhees bert.verhees at rosa.nl 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 bert.verhees at rosa.nl 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.htmlhttp://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

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 bert.verhees at rosa.nl 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 serefarikan at kurumsalteknoloji.com
 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 bert.verhees at rosa.nl 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

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.
xs:element name=items type=LOCATABLE/

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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121127/ac7c080c/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 bert.verhees at rosa.nl 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.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

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
http://www.openehr.org/wiki/download/attachments/786486/EEE-v1.xsd?version=
1modificationDate=1349637658000 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 VERSIONT.uid as owner_id,
creating_system_id, version_tree_id, there is also an operation
VERSIONT.owner_id().
2.  common_im p. 40 says VERSIONT.owner_id() extracts the uid of the
owning VERSIONED_OBJECT.
3.  common_im p. 46 says the VERSIONT.uid is object_id,
creating_system_id, version_tree_id.
4.  common_im p. 46 says the object_id part of the VERSIONT.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_OBJECTT 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 

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 

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 

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 pazospablo at hotmail.com 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
VERSIONCOMPOSITION) 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
VersionCompositon) should be referenced by a Contribution. Also, each
VersionComposition 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 

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 IDs 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_RELATIONSHIPs. What do you think?

 __**_
 openEHR-technical mailing list
 openEHR-technical at lists.**openehr.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://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/20120905/c7e6cd6d/attachment.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
heath.frankel at oceaninformatics.com 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 will be
(in dADL):

items = 
[1] =  -- ELEMENT
archetype_node_id = at0004
value

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

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 pazospablo at hotmail.com 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 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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120618/e2224d7f/attachment.html

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 erik.sundvall at liu.se 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 pazospablo at hotmail.com
 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 peter.gummer at oceaninformatics.com:
   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
 
  ___
  openEHR-technical mailing list
  openEHR-technical at lists.openehr.org
 
 

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 pazospablo at hotmail.com 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 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 pazospablo at hotmail.comwrote:

  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 

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 serefarikan at kurumsalteknoloji.com
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 pazospablo at hotmail.comwrote:

  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 semantics
 and I think can be used as a lossless serialisation. Others may have more
 evolved ideas on how 

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]

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/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.pdfhttp://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.orgopenEHR-technical at 
 lists.openehr.org
 http://lists.openehr.org/**mailman/listinfo/openehr-**
 technical_lists.openehr.orghttp://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/20120508/44eb3365/attachment.html

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:

 

current_state

valueCompleted/value

defining_code

terminology_id


value532/value

/terminology_id


code_stringopenehr/code_string

/defining_code

/current_state

 

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

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 serefarikan at kurumsalteknoloji.com
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 serefarikan at 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 thomas.beale at 
 oceaninformatics.comwrote:


 I have to say, software development would be absolutely dire from my
 point of view without one particular generic type: HashT, K. 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 peter.gummer@??oceaninformatics.com peter.gummer 
 at 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

  IteratorDvText 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 Map Integer, String

 Generics is useful to declare what instance is, but it breaks

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 serefarikan at 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 at oceaninformatics.com wrote:


 I have to say, software development would be absolutely dire from my
 point of view without one particular generic type: HashT, K. 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 peter.gummer@?oceaninformatics.com peter.gummer at 
 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

  IteratorDvText 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 Map Integer, String

 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 
 http://se.ethz.ch/%7Emeyer/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 openEHR-technical at 
 lists.openehr.orghttp://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 
http://www.healthintersections.com.au/wiki/index.php?title=Non-ucum_units_in_Quantity
  - 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: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/ce91de2c/attachment.html

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 k.atalag at auckland.ac.nz 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 mdckoury at gmail.com
 escreveu:

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

 ** **

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

 ** **

 Best Regards,

 ** **

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


 

 2012/2/17 pablo pazos pazospablo at hotmail.com

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

 ** **

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

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

 :D

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

 ** **

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



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

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


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


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

 ** **

 ** **

 ** **

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

 ** **

 The message was checked by ESET NOD32 Antivirus.

 ** **

 http://www.eset.com


 __ 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120221/10b0ee3a/attachment.html

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 thomas.beale at oceaninformatics.com
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 http://en.wikipedia.org/wiki/ClearHealth 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 http://www.oreillynet.com/pub/au/4766 on the O'Reilly
 website repeats the same error. This 
 reviewhttp://shop.oreilly.com/product/0636920020110.do#PowerReviewon 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120214/7925255b/attachment.html

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 Ian.McNicoll at oceaninformatics.com
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
 heath.frankel at oceaninformatics.com wrote:
  Hi Ian,
  Interested in how you think RLUS can support a Knowledge service?
  Heath
 
  On 01/02/2012 2:21 AM, Ian McNicoll Ian.McNicoll at oceaninformatics.com
 
  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 pazospablo at hotmail.com 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 pazospablo at hotmail.com
 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

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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120206/c0752553/attachment.html

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 erik.sundvall at liu.se 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 erik.sundvall at liu.se 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

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 Ian.McNicoll at oceaninformatics.com
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 pazospablo at hotmail.com 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 pazospablo at hotmail.com 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 ..
  
   1. Add some sort of persistence/ repository back-end for archetypes
   and associated documentation e.g Github and/ or Dropbox. There is a
   very nice Python API for the latter which I got working. This does
 not
   need to be be particularly complex. Github would probably be a better
   solution but 

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 erik.sundvall at liu.se 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 archetype is as follows:

 annotations
 items = 
 [en] = 
 items = 
 [/data[at0001]/items[at0.8]] = 
 items = 
 [design note] = this is a design note on
 allergic reaction
 [requirements note] = this is a requirements
 note on allergic reaction
 [medline ref] = this is a medline ref on
 allergic reaction
 
 
 [/data[at0001]/items[at0.10]] = 
 items = 
 [design note] = this is a design note on
 intelerance
 [requirements note] = this is a requirements
 note on intolerance
 [national

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
need any new tools to process these directives - the main archetype compiler
would

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 thomas.beale at oceaninformatics.com

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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/93ab2c2a/attachment.html

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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120130/55d5f522/attachment.html

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:

 

xs:complexType name=T_VIEW

  xs:sequence

xs:element name=constraints  minOccurs=0 maxOccurs=unbounded

  xs:complexType

xs:sequence

  xs:element name=items maxOccurs=unbounded 

xs:complexType

  xs:sequence

xs:element name=value type=xs:anySimpleType/

  /xs:sequence

  xs:attribute name=id type=xs:string use=required/

/xs:complexType

  /xs:element

/xs:sequence

xs:attribute name=path type=xs:string use=required/

  /xs:complexType

/xs:element

  /xs:sequence

/xs:complexType

 

An example use of this is as follows:

 

template xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns=http://schemas.openehr.org/v1;

.

  view

constraints
path=/content[openEHR-EHR-OBSERVATION.lab_test.v1]/data[at0001]/events[at00
02]/data[at0003]/items[openEHR-EHR-CLUSTER.specimen.v1]/items[at0046]

  items id=pass_through

valuetrue/value

  /items

/constraints

  /view

/template

 

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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120113/487e0f28/attachment.html

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 heath.frankel at oceaninformatics.com
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 peter.gummer at oceaninformatics.com
 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

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 pazospablo at hotmail.com 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 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120111/164f0a7f/attachment.html

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 thomas.beale at oceaninformatics.com
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
 modelhttp://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109597816149_873308_762Report.html(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 would allow CR/LFs to occur
 in 

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? yampeku at gmail.com 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)


 children xsi:type=C_CODE_PHRASE
rm_type_nameCODE_PHRASE/rm_type_name
occurrences
  lower_includedtrue/lower_included
  upper_includedtrue/upper_included
  lower_unboundedfalse/lower_unbounded
  upper_unboundedfalse/upper_unbounded
  lower0/lower
  upper1/upper
/occurrences
node_idat0009/node_id
terminology_id
  valuelocal/value
/terminology_id
code_listat1000/code_list
code_listat1001/code_list
code_listat1002/code_list
code_listat1003/code_list
code_listat1014/code_list
  /children

 Can we reach a quick consensus on how should this be stated? Can we
 use an assumed_value 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120106/bbfb17b6/attachment.html

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 serefarikan at kurumsalteknoloji.com
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 erik.sundvall at liu.sewrote:

 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120106/12ee3e66/attachment.html

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

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 heath.frankel at oceaninformatics.com:
 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

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 revise the openEHR specs, to see if this topic is
clear enough, because I don't see

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 Integer is actually worthwhile. (Once again thanks for
that page, its quite a good way to get a good feel for these syntaxes very
quickly).

- thomas

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

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
thomas.beale at oceaninformatics.com 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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111202/92bf7a06/attachment.html

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: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2015/dfb76841/attachment.html

occurrences and cardinality in ADL, XML, JSON

[Heath Frankel]

I too have no problem with this custom serialisation as I have a hand-coded
serializer that does the job (I gave up on the auto-generated ones years
ago).

However, I think we need to go back a step and get agreement from the
community what the most important features of an XML serialization are:
readability, size, auto-generation etc.  Once we get some sort of ranking
then we can score each implementation choice accordingly.

I personally don't see the need to have consistently between different
serialization formats, I think we should make the decisions that are best
for the particular format.  Having said that, I would be surprised if the
logical features of the different formats would be different unless there
intended use are dramatically different (i.e. the importance of
auto-generation is likely to be the same for both JSON and XML). 

Heath

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Andrew Patterson
 Sent: Saturday, 12 November 2011 12:26 AM
 To: For openEHR technical discussions
 Subject: Re: occurrences and cardinality in ADL, XML, JSON
 
 On 11/11/2011 11:50 PM, Thomas Beale wrote:
  occurrences: 1..*
  well that's my opinion as well, and XML-ers always react badly! The
  'proper' parser code for dealing with this form, used in the ADL
 parser
  is (from the .y file):
 
 Well I consider myself an XML-er and I don't see massive problems with
 it, but
 maybe I have become soft in my old age.
 
 My main argument would be that the XML at one point was almost a
 straight serialization
 of the object model, as supported by various XML data binding
 libraries. So
 XML - AOM memory objects - XML was all doable with very standard
 binding libraries.
 
 BUT
 
 I was happy with status quo because I don't really care about the
 size of the XML or how often elements are repeated or the fact that is
 looks
 ugly to people - if people want compressed data then they should use
 fastinfoset
 or exi, and then gzip and it'll compress beautifully. The
 size/format/look
 is a concern to others.
 
 BUT
 
 If I have lost the battle and if we are going to do customised
 XML serializations then once you've taken it outside the
 normal data binding by introducing * forms or even
 'properties' that aren't really properties but kind of quasi computed
 fields
 then you mind as well as give up on the pretence that the XML
 serialization
 will bind straight into an AOM compatible object model..
 in which case parsing 1..* is not a problem
 
 Andrew
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

occurrences and cardinality in ADL, XML, JSON

[Heath Frankel]

Hi Thomas,

The answers to the two questions below seem to be counter to each other.  I
think if we want to stay true to the RM that we should do this consistently,
otherwise there is no reason why we can't deviate in other cases such as the
first case below.  In fact I would go further and suggest a syntax such as
occurrences = 2..* in dADL and similar in XML.  

 

However, others may not be so keen on this as those starting out with
openEHR like to use the built-in development tools in their favourite IDE to
generate classes that match the AM/RM and automatically serialize data.
This is certainly where I started but soon found limitations in this
approach and now have a custom serializer.  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. 

 

Regards

 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 11 November 2011 4:42 AM
To: Openehr-Technical
Subject: occurrences and cardinality in ADL, XML, JSON

 


In the current ADL 1.4-based XSDs used in openEHR, occurrences, cardinality
and existence are expressed as XML elements. We will want to improve this
for ADL 1.5 based XML. Now, we don't want to only take care of XML; we also
need to make it work for JSON, and (internally) for dADL - neither of the
latter have XML's 'attributes'. Many people have asked for more efficient
ways of serialising. Here are some ideas for ADL 1.5 XML, JSON etc.

~~ first question: occurrences and cardinality  
Occurrences and cardinality  are proper intervals in the AOM representation.
The most simplified object structure (JSON and dADL) for occurrences and
cardinality could look as follows (I use dADL  occurrences here):

occurrences = 
lower = 2 -- Integer field
upper = 10 -- Integer field


but the upper limit is commonly unbounded, i.e. '*' in typical UML-like
syntax. We could do:

occurrences = 
lower = 2 -- Integer field
upper_bounded = True -- Boolean field


meaning that 3 possible attributes could occur for an occurrences, but only
ever 2 at the same time. Or we could make everything into a string:

occurrences = 
lower = 2 -- String field
upper = * -- String field


The upside is that the 'upper' attribute now handles both bounded and
unbounded values. The downside is that the JSON / dADL parsers would have to
do a bit more work to generate the required IntervalInteger object - since
the 'upper' attribute now has to be treated as a little fragment of syntax
and checked before being turned into an Integer. 

If we were just doing JSON, dADL and other 'proper' OO syntaxes, the first
one would be the obvious one. But since we are also targetting XML, we have
to think whether it makes more sense to do:

   children node_id=at0005 occurrences_lower=2
occurrences_upper=10 -- xsi:type=C_OBJECT
   rm_type_nameCLUSTER/rm_type_name
 
and

   children node_id=at0005 occurrences_lower=2
occurrences_unbounded=true -- xs:boolean has to support 0/1 and
true/false
   rm_type_nameCLUSTER/rm_type_name
 
which is the analog of the first approach above, or it could be:

   children node_id=at0005 occurrences_lower=2
occurrences_upper=10
   rm_type_nameCLUSTER/rm_type_name
 
and

   children node_id=at0005 occurrences_lower=2
occurrences_upper=*
   rm_type_nameCLUSTER/rm_type_name

with both attributes defined in the XSD as xs:string. This means that like
for JSON/dADL, the XML standard parser only generates strings, and somehting
further has to be done to obtain a proper Interval object. 

My preference is still to go with the first way of doing things. Do others
agree with this? If so, it is what I will implement in the ADL 1.5
workbench. 

~ second question:existence 
Existence as an interval can be 0..0 (prohibited, commonly used in
templates), 0..1 (optional, typical in the RM) and 1..1 (used in templates
and sometimes in archetypes). Now, since archetypes and templates are
constraint structures, they can only further constrain the RM in ADL/AOM
1.5. The only possibilities for this are actually 0..0 and 1..1, so we
could collapse existence onto a single Boolean for serialised representation
(it could also be a single Boolean in the AOM, but that would be a breaking
change, and since we already use Intervals for occurrences and cardinality,
it does not seem worth the trouble). 

Thus in JSON/dADL it could be:

some_attr = 
existence = True|False


In XML:

attributes rm_attribute_name=nameexistence=true
   
/attributes

Now, this is cheating a bit because we are making it look like there is an
AOM property 'existence' of type Boolean, but there isn't. Should it be
named something else to make this clear? I.e. a pseudo attribute that only
exists in serialised format but not in AOM internal format, e.g.

Questions about the necessity of ITEM_SINGLE

[Heath Frankel]

Hi Sam,

The problem with this is that we currently use the RM inheritance to assist
in these structure constraints, i.e. an ITEM_LIST only contains a CLUSTER
containing only ELEMENTs.  However, if you think about it, the semantics of
CLUSTER and ITEM_TREE are equivalent.  It is only the level in the model
that is different.  The question is, would it be helpful to have other
ITEM_STRUCTURE subtypes within an ITEM_STRUCTURE, i.e. an ITEM_TREE
containing an ITEM_LIST or ITEM_TABLE.  This is certainly the case in
CEN13606 with the mandatory CLUSTER.structure_type attribute.

 

I think we need to go back and ask, why are we trying to simplify
ITEM_STRUCTURE?  Are we doing it to simplify the RM, archetypes or data?

 

For me the data is of interest and it is about 10 years since I first
questioned Thomas about the need for ITEM_STRUCTURE.  Not only does it
lengthen paths but it requires a whole level in data that is necessary and
requires mandatory structural only attribute values such as node_id and
name.

 

From a domain model perspective I see the value of supporting additional
properties and methods on these sub-classes but in a persistence model they
add no value, we just need to know which domain class to materialise.  In
XML this can be done using the built-in schema type attribute and this
approach would support XML-class generator libraries, whereas using the CEN
13606 model defined attribute would require an additional adapter to
materialise the domain model class.  My point is, we probably need to
separate the RM representation from the persistence ITS.  Even with the
current RM, we could probably simplify the XML schema to collapse this level
of data, although we still need a way to represent the mandatory node_id and
name attributes of the ITEM_STRCTURE.  This would be easier if they were not
mandatory, but that is topic for another day.

 

However, if we want a RM change with migration path, the minimal change that
I can see is to make ITEM inherit from ITEM_STRUCTURE.  We could make the
ITEM_SINGLE, ITEM_TREE, ITEM_TABLE and ITEM_LIST sub type of CLUSTER but the
only true sub type of CLUSTER is ITEM_TREE.  In future we could merge
CLUSTER and ITEM_TREE and remove ITEM_SINGLE.

 

Regards

 

Heath

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Sam Heard
Sent: Monday, 10 October 2011 1:40 PM
To: 'For openEHR clinical discussions'
Subject: RE: Questions about the necessity of ITEM_SINGLE

 

Hi

 

My (clinician?s thinking) idea was to have ITEM_STRUCTURE inherit from
Cluster (it is a fancy one anyway). This would make ITEM_TREE and
ITEM_SINGLE redundant allow ITEM_LIST to be used as a constraint on Cluster
to only allow ELEMENTS.

 

ITEM_TABLE could then have additional attributes .

 

Cheers, Sam

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Thursday, 6 October 2011 5:22 AM
To: openehr clinical
Subject: RE: Questions about the necessity of ITEM_SINGLE

 

Done: http://www.openehr.org/issues/browse/SPECPR-74

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

  _  

Date: Tue, 4 Oct 2011 17:07:27 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-clinical at openehr.org
Subject: Re: Questions about the necessity of ITEM_SINGLE

On 04/10/2011 16:18, pablo pazos wrote: 

Hi!

Your comments are very interesting, and I think we all converge to the same
point.

For the transition steps mentioned by Thomas, I think we could do quick
change with backwards compatibility, adding things without removing the
ITEM_STRUCTURE package.
We could do a fork also, and start to work in a new model without affecting
current tools, and join the specs, tools and archetypes at some point on the
future.


Now, how do we proceed? I don't know if there's a formal way to do a Change
Request to the RM. I don't want to leave this issue to die on the lists.


yep there is - post a problem report issue here
http://www.openehr.org/issues/browse/SPECPR .

- thomas


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

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

AQL VersionedObject Grammar

[Heath Frankel]

Yes, from memory this be about right, but the VERSIONED_OBJECT part is
redundant as it is not used anywhere in the query.

I notice you are specifying a HIER_OBJECT_ID as the COMPOSITION.uid
criteria.  Although it is not a specified and not a hard rule, it is
recommended that a OBJECT_VERSION_ID is used in the COMPOSITION.uid
otherwise you have no way of getting the exact version of a composition when
the composition is separated from the VERSION object.

Heath

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of mahdi.asgari at gmail.com
 Sent: Tuesday, 19 July 2011 11:00 PM
 To: openehr-technical at openehr.org
 Subject: Re: Re: AQL VersionedObject Grammar
 
 Thanks Ian
 
 Is the bellow EQL query correct for query in all versions of a
 composition ?
 
 SELECT  v/commit_audit/committer/name,
 v/commit_audit/time_committed/value,
 v/data/uid, v/data/time_created, c FROM EHR e [ehr_id/value =
 'ecfe6e6e-8868-4fc6-8db8-def71cb8a250'] CONTAINS VERSIONED_OBJECT vo
 CONTAINS VERSION v [all_versions] CONTAINS COMPOSITION
 c[openEHR-EHR-COMPOSITION.encounter.v1]
 Where c/uid = 'hierobjectid'
 
 --
 
 Message: 2
 Date: Tue, 19 Jul 2011 07:37:41 +0100
 From: Ian McNicoll Ian.McNicoll at oceaninformatics.com
 Subject: Re: AQL VersionedObject Grammar
 To: For openEHR technical discussions openehr-technical at openehr.org
 Message-ID:
   CAG-n1KzEE1mAFKcqqnGxfxFr3fOuJPz-
 qfcDe6FovusQBwwpgQ at mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hi Mahdi,
 
 SELECT  v/commit_audit/committer/name,
 v/commit_audit/time_committed/value, v/data/uid, v/data/time_created, c
 FROM
 EHR e [ehr_id/value = 'ecfe6e6e-8868-4fc6-8db8-def71cb8a250']
 CONTAINS VERSION v
 CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.encounter.v1]
 
 should return commit _audit and versioned_object attributes for all
 Encounter compositions.
 
 Ian
 
 Dr Ian McNicoll
 office +44 (0)1536 414 994
 fax +44 (0)1536 516317
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com
 
 Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical
 Knowledge Editor www.openehr.org/knowledge Honorary Senior Research
 Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org
 
 
 
 
 On 19 July 2011 06:50,  mahdi.asgari at gmail.com wrote:
  Hi dear All
 
  I confuse to make a AQL query using versioned_object or Version,
 
  Does anyone know some example of using versioned_object and version?
 
 
 
  Thanks in advance
 
 
 
  Mahdi Asgari
 
  
 
  Naji Research and Development
 
  EHR Technical Manager
 
  
 
  Gmail:mahdi.asgari at gmail.com
 
  Y! Messenger: mahdiiran
 
  ooVoo: mahdi.asgari
 
 
 
  ___
  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
 
 
 End of openEHR-technical Digest, Vol 60, Issue 5
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

CCR model

[Heath Frankel]

Hi Koray,
In 2009 I did an IHE Medical Summary profile based Template for the
Interoperability Demonstration at HIC.  I can't recall the exact
relationships between CCR, CCD and IHE Medical Summary profiles but they
pretty much cover the same concepts.  The template was only a subset of the
Referral Summary but did cover Service request, History of present illness,
Active problems, Current Medications, Allergies, History of past Illness,
Past surgical history, Family history and Social history.

This may be the start you were looking for, or at least something to have a
look at.  Obviously the Archetypes used were from an old point in time on
CKM so I will need to bundle up a package and send it to you separately if
you're interested.  You will then need to upgrade these to the latest
release of archetypes.

You may be interested to know that I used this template to generate a
Template Data Schema (XML Schema) to assist in the transformation of a HL7
V2 REF message sent from another vendor, which was coded using the IHE
Medical Summary profile recommended LONIC codes, into both an openEHR
composition and a Referral Summary CDA.  The CDA document was then sent to
another vendor's XDS.b repository.

Regards

Heath

 -Original Message-
 From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical-
 bounces at openehr.org] On Behalf Of Ian McNicoll
 Sent: Monday, 11 July 2011 4:07 PM
 To: For openEHR technical discussions
 Cc: For openEHR clinical discussions
 Subject: Re: CCR model
 
 Hi Koray,
 
 You may be better to look at CCD, the HL7/CDA variant, rather than CCR
 itself, as I think CCD has much more international take up, via
 templated CDAs. If you look at various IHE profiles you will get
 examples - the MDHT site is a good source of documentation
 http://cdatools.org/infocenter/index.jsp?topic=/org.openhealthtools.mdh
 t.cda.doc.user/c_Introduction.html
 
 Ian
 
 Dr Ian McNicoll
 office +44 (0)1536 414 994
 fax +44 (0)1536 516317
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com
 
 Clinical Modelling Consultant,?Ocean Informatics, UK
 openEHR Clinical Knowledge Editor www.openehr.org/knowledge
 Honorary Senior Research Associate, CHIME, UCL
 BCS Primary Health Care ?www.phcsg.org
 
 
 
 
 On 11 July 2011 07:27, Diego Bosc? yampeku at gmail.com wrote:
  Hello Koray,
 
  ASTM sells the standard + the schema, so I think the only way to
  obtain it is to buy it from them
  http://www.astm.org/Standards/E2369.htm
 
  regards
 
  2011/7/11 Koray Atalag k.atalag at auckland.ac.nz:
  Hi All, I need CCR model ASAP. has anyone worked on this. Possible
 to share?
 
 
 
  Cheers,
  -koray
 
  ___
  openEHR-clinical mailing list
  openEHR-clinical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
 ___
 openEHR-clinical mailing list
 openEHR-clinical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

openEHR artifact namespace identifiers

[Heath Frankel]

Source file class in a program language have names and in the cases of COM
they have an ID such as a GUID.  The issue here is related to the later, not
the former.

 

More than happy with a GUID, in fact our knowledge resource repository does
exactly what David Moner proposed, it assigns a resource ID (GUID) and
maintains a version tree ID.

 

Really I don't see the difference between a GUID and OID, as you say
elsewhere, they are just strings.  It is just the process used to create the
string that differs and when we start introducing governance with publishing
organisations, having an OID root for the publishing organisation and an
extension for each artefact generated by a repository system aligns so
nicely with the OID approach I can't understand why we so easily blow this
option off.  

 

Once we have a reliable UID of some kind we can generate URIs.  The
alternative of generating a composite UID from meta data sounds complicated,
contentious, unreliable and frankly worse than the same kind of issues you
have with OIDs.

 

Heath 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 29 April 2011 2:16 AM
To: openehr-technical at openehr.org
Subject: Re: openEHR artifact namespace identifiers

 

On 08/04/2011 01:49, Heath Frankel wrote: 

Thomas,

Your proposed changes to the archetype Identifiers and governance actually
aligns with the same management and inferencing requirements as OIDs, the
only benefit left is the readability, but even that is becoming hard to do
with the additional namespaces and delimiters.  In addition, having
meaningful IDs and deriving meaning from IDs is counter to what good
practice in terminology identifier management.


for atomic concepts a la SNOMED, meaningless identifiers make sense; for
complex artefacts like programming language source files - of which
archetypes are an example, they don't really - they just obscures meaning
from developers. Meaningless identifiers of the Guid variety make sense for
deployed versions of these artefacts - i.e. generated template OPTs,
assemblies etc. Where identification really matters is a) in data and b) in
deployed software artefacts that were generated from templates  archetypes.

The future may well be to do as David Moner (I think, or maybe Diego, can't
remember now) said - to create archetype meta-data attributes to carry the
pieces of the id, and generate the strings that we currently use as ids when
and as needed. Attaching Guids to source archetypes can also be done
obviously, but I think for source artefacts, Oids provide little gain and a
lot of pain. 

- thomas




 

 

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

Archetype versioning on CKM

[Heath Frankel]

The problem is that ontologically v1 is not actually a version identifier,
it is more like an axis of a concept ID, v1 and v2 have different concepts
although they represent the same concept domain (i.e. two different
representations of the same concept).  The name of this axis is an
unfortunate legacy that keeps causing similar discussion threads.  One
reason why meaningless identifiers would be an improvement.

Heath

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Diego Bosc?
 Sent: Wednesday, 27 April 2011 7:15 PM
 To: For openEHR clinical discussions
 Cc: For openEHR technical discussions
 Subject: Re: Archetype versioning on CKM
 
 I still don't see the problem
 
 If we wait until an archetype is published to care about versions then
 you will have v2 or v3 archetypes as much, which in my opinion breaks
 completely versioning purpose. What is the problem with having a v27
 archetype? Is it less pretty?
 
 2011/4/27 Ian McNicoll Ian.McNicoll at oceaninformatics.com:
  Hi David,
  Thanks for this, though I think these are still draft specifications.
 I had
  some input into that document but with experience I am not sure the
 revision
  rules really work for .v0 archetypes though the .v0 idea itself is
 useful.
  The problem is that any structural version changes would force us to
 move
  from v0-v1, which is what I think we need to avoid for these first
 draft
  archetypes. Once an archetype is published, the rules suggested
 (mostly)
  work just fine
  Ian
  Dr Ian McNicoll
  office +44 (0)1536 414 994
  ?? ? ? ? +44 (0)2032 392 970
  fax +44 (0)1536 516317
  mobile +44 (0)775 209 7859
  skype ianmcnicoll
  ian.mcnicoll at oceaninformatics.com
 
  Clinical Modelling Consultant,?Ocean Informatics, UK
  openEHR Clinical Knowledge Editor www.openehr.org/knowledge
  Honorary Senior Research Associate, CHIME, UCL
  BCS Primary Health Care ?www.phcsg.org
 
 
 
  On 27 April 2011 10:15, David Moner damoca at gmail.com wrote:
 
 
  2011/4/27 Ian McNicoll Ian.McNicoll at oceaninformatics.com
 
 
  Would calling first draft archetypes .v0 help to highlight their
  fragility?
 
 
  In fact, that is what the specifications say. Our archetype editors
 should
  use 0 when creating a new archetype.
  (Knowledge Artefact?Identification specifications)
  .v0 rule: all archetypes have this version on initial creation,
 before
  being accepted by the
  collaborative authoring environment;
  revision id rule: revision number starts at 0 and is incremented
 whenever
  a backwards
  compatible change is made that affects the structure ? by widening
  constraints and/or adding
  new nodes;
  commit id rule: commit number starts at 0 and increments for any
 change at
  all to an archetype,
  including changes to meta-data, addition of translations and so on.
  An archetype will start its life as a ?v0? artefact, and with no
  namespace. In this form, it can have any
  number of revisions and commits. It may be maintained for some time
  outside a Publishing Organisation,
  or it may be offered to a PO, where it will initially become part of
 an
  ?alpha? development area.
  where it will remain until its identifier and location in the
 package and
  Library structure is stablised.
  Once stable, an alpha archetype will migrate to the main ?dev? area,
 where
  it will be given a namespace
  prefix and have its version incremented to ?v1?. At this point it
 could be
  published into the
  ?release? area, or alternatively, further development may occur
 before
  publishing. Whenever the revision
  is changed, due to a backwards-compatible structural change, the
 archetype
  should be re-published,
  enabling the community to have access to the latest form of the
 archetype.
  During development, each change will increment the commit number.
 Whenever
  an archetype is published,
  the commit number is reset to 0.
 
 
 
  --
  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)
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
 
  ___
  openEHR-clinical mailing list
  openEHR-clinical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR artifact namespace identifiers

[Heath Frankel]

Exactly, an OID can be used as an URI scheme.

 

Not sure how much simpler you can get then assigning a string of numbers and
dots to a system that issues an accession number and appends it the assigned
string, CKM already does the first two steps of this.Anyone that can
implement a openEHR -based health record service or an ADL parser should be
able to cope with this.

 

Anyway, I am happy with a URI as long as we leave open the scheme choice in
ADL/AOM and adopt a limited set of standard schemes for openEHR archetypes
rather than invent a new one.  However, it does mean a substantial change to
the AOM compared with using the existing UID attribute of type
HIER_OBJECT_ID.  A URI can always be constructed from this as is done with
EHR URIs.

 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 8 April 2011 11:50 PM
To: openehr-technical at openehr.org
Subject: Re: openEHR artifact namespace identifiers

 

On 08/04/2011 14:28, pablo pazos wrote: 

Hi Heath,

Just analysing OIDs vs. URIs:


Usage:
OIDs are in use in health informatics and other areas.
URIs are in use everywhere in form of URLs

Procesing:
OIDs lack internal processing
URIs can be processed

Compatibility with actual identifiers:

Inside archetypes, each node can be identified by a path, so if we use URIs
to identify an archetype, just appending the path to the URI we get a valid
URI to identify a node inside the archetyp.


I go with URIs.


if you have a look at the Architecture
http://www.openehr.org/releases/1.0.2/architecture/overview.pdf  Overview
spec, this is documented in some detail (more is needed... next release ;-).
When Tony Shannon and I met a couple of years ago with Tim Berners-Lee, this
was almost the only thing he found significant - that we could point to any
knowledge model node or data instance node with a proper URI. Of course you
can stick an Oid inside a URI, but I am still very unconvinced about Oids. I
don't like making things complex when they can be simple.

- thomas beale

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

openEHR artifact namespace identifiers

[Heath Frankel]

Thomas,

Your proposed changes to the archetype Identifiers and governance actually
aligns with the same management and inferencing requirements as OIDs, the
only benefit left is the readability, but even that is becoming hard to do
with the additional namespaces and delimiters.  In addition, having
meaningful IDs and deriving meaning from IDs is counter to what good
practice in terminology identifier management.

 

If we choose a GUID (or any other standard UID) for the archetype ID, then I
see no reason why the VersionedObjectId scheme cannot be used for managing
versions of the archetype as long as it is properly administered.

 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 8 April 2011 1:11 AM
To: openehr-technical at openehr.org
Subject: Re: openEHR artifact namespace identifiers

 


Oids probably are the one kind of id I would not propose for archetypes; the
multi-axial id in current use + the proposed namespace id is equivalent to
an Oid, just with some more constrained rules on what is on the axes, and
readable values. The need for a highly managed id assignment system plus
loss of readability and inferencing capability seems like a backward step to
me. UUIDs seem a more obvious step. Note that UUIDs don't cope properly with
namespaces nor versions, and there are already id systems that assign a UUID
to the 'artefact' and a second UUID to the version, so that it can be
inferred if two concrete artefact instances are really just versions of the
same thing. Note that a UUID is massive overkill for a version id of
something! But this just shows that simple assignment of UUIDs or Oids is no
panacea

- thomas

On 06/04/2011 01:41, Heath Frankel wrote: 

 
 
 
 
Personally, I would like to propose the use of OIDs for controlled artefacts
as it is an ISO standard and already used in health informatics for
identifying such knowledge artefacts such as terminologies.  I know OIDs are
not liked due their length, unreadability and managed allocation, but to me
it is a natural fit for this kind of artefact ID.  Each publishing
organisation can get an OID and manage the items that they produce, this can
be done using a content management system automatically as is done by CKM.
And to be honest, the new namespaced ID scheme is likely to be longer and
requires management, and barely legible once we include the namespace and
additional delimiters.
 
 
 

 

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

openEHR artifact namespace identifiers

[Heath Frankel]

Hi Ian,

This sounds more sensible to me, I was always worried about the change in
identifier when it got escalated to a higher PO.  

 

I wonder if we can get a summary of the rest of the SNOMED namespacing
scheme so that we can see if it is usable in its entirety.

 

I have always been a supporter of the readable identifiers but I am now
starting to see their limitations in reality.  I think we should seriously
consider an existing standard unique identifier scheme (UUID/GUID or OID)
rather than trying to invent a new one.  I understand that there are issues
with using these existing schemes but I can't say that I am seeing that
namespaced archetype ID helps these issues, the only benefit is some
readability but this is countered by clashes in the wild and the governance
overhead to get it controlled.

 

The Archetype class has a UID attribute, I think we need to start using this
as an object identifier, after all an archetype is an object.  In the
artefact maintenance area, we can start using the ObjectVersionId scheme to
manage the PO (creating system) and revisions.  Alternatively we can use a
single OID to represent the PO with a root and the artefact ID as an
extension.

 

The issue with this suggested change is that we will have to work out how we
make this work with the existing archetype IDs used in data or transition
away from using existing archetype IDs.  In the short term I think we need
to concentrate on template identifiers as the problem is worse with many
more organisations producing templates that overlap and less being reused
between organisations.  Therefore, we can try a standard UID approach for
templates without the legacy and once we have this sorted we can look at
integrating back into archetypes.  

 

Personally, I would like to propose the use of OIDs for controlled artefacts
as it is an ISO standard and already used in health informatics for
identifying such knowledge artefacts such as terminologies.  I know OIDs are
not liked due their length, unreadability and managed allocation, but to me
it is a natural fit for this kind of artefact ID.  Each publishing
organisation can get an OID and manage the items that they produce, this can
be done using a content management system automatically as is done by CKM.
And to be honest, the new namespaced ID scheme is likely to be longer and
requires management, and barely legible once we include the namespace and
additional delimiters.

 

We can also have a fallback to GUID for organisations that don't have an OID
and a knowledge management system to maintain an OID.  This would be the
default when a new template is created in a template editor but can be
upgraded to an OID once submitted to a knowledge management system.

 

Regards

 

Heath 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Ian McNicoll
Sent: Wednesday, 6 April 2011 1:21 AM
To: For openEHR technical discussions
Subject: openEHR artefact namespace identifiers

 

Hi,

 

About a year ago Thomas published a draft of some detailed artefact
identification proposals at
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/kn
owledge_id_system.pdf

 

to help with the rapidly approaching scenario of having to cope with
similarly named artefacts being published by different authorities. We are
starting to see this scenario emerging  in real-world projects and whilst
potential collisions can be managed informally for now, we will need a
formal mechanism before long.

 

I would like to raise one aspect which I think might need re-thought on the
basis of recent IHTSDO proposal for SNOMED covering the same ground.

 

In the pdf Thomas says

 

 When an archetype is moved from its original PO (e.g. a local health
authority, or a specialist peak

body) to a more central authoring domain (e.g. a national library,
openEHR.org) its namespace will be

changed to the new domain, as part of the review and handover process. The
archetype's semantic

definition may or may not change. In order for tools to know that an
archetype was not created new

locally, but was moved from another PO, an explicit reference statement can
be made in the archetype

in the description section of an archetype as follows:

 

id_history = se.skl.epj::openEHR-EHR-EVALUATION.problem.v1

 

The IHTSDO proposals cover  the same scenario i.e a SNOMED code originally
authored in one namespace subsequently being managed in a new namespace. A
good example might be a SNOMED term which is originally used t a national
level but is then adopted internationally. They suggest that the term keeps
its original authored namespace, and it is the namespace of the managing
entity that changes, arguing that this is much less disruptive to systems
that are using the term concerned.

 

I think we should consider adopting the same approach for openEHR
archetypes, as otherwise the formal identifier of an archetype will change
if a locally 

future ADL-versions

[Heath Frankel]

Hi Seref,
I agree with you sediments regarding Archetypes.  However, the AOM still
needs to support something like this for templates, in my view this is the
level where we will want to start making conditional statements about data
constraints (and this is still before we get to the GUI, as I may have the
same conditional constraint requirement in an integration scenario).  

Heath

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Seref Arikan
 Sent: Wednesday, 23 March 2011 10:03 AM
 To: For openEHR technical discussions
 Subject: Re: future ADL-versions
 
 Greetings,
 I have a single question about this particular requirement/idea: why?
 
 Archetypes are model artefacts. That is it. They are supposed to
 describe domain models in a certain way. Behaviour or software that
 uses those models is a completely different thing. I can understand a
 constraint which references another one for defining a valid interval
 etc, but how on earth something like forcing a user for another entry
 is going to be handled during implementation? How would one express
 this in common formalisms like XML?
 
 I could understand a suggestion to use ADL to express rules regarding
 the archetypes, but that should be a formalism leaving in a separate
 space, which may be linked to archetypes, which
 only-contain-constraints-on-RM-types.
 
 Please keep behaviour our of models in ADL specifications.
 
 Regards
 Seref
 
 
 On Fri, Mar 18, 2011 at 8:10 PM, Bert Verhees bert.verhees at rosa.nl
 wrote:
  Thanks, Thomas, for your reply. There is more to it then I initially
  thought of.
 
  I am not very familiar with XPath. Best is to wait for more
 information
  on the specs.
  This is enough for now, to let customers give something to think
 about.
 
  Bert
 
  On 16-03-11 19:32, Thomas Beale wrote:
 
  Hi Bert,
 
  I hope to get back on the spec in the next couple of weeks. With
 respect
  to your specific question below, can you be a bit more precise?
 There
  are ways to express this kind of thing, but we need to be clear on
  distinguishing references to:
 
  ? ? * elements in the same archetype - as in a rule like:
  ? ? ? ? ? o /path/to/systolic/pressure/value 
  ? ? ? ? ? ? /path/to/diastolic/pressure/value
  ? ? * elements in data elsewhere in the same EHR like:
  ? ? ? ? ? o $date_of_birth:ISO8601_DATE ::= query(?ehr?,
 ?date_of_birth?)
  ? ? ? ? ? o this is still being finalised, so don't depend on it;
  ? ? ? ? ? ? however it is the left hand side that matters, i.e.
  ? ? ? ? ? ? $date_of_birth
  ? ? * environmental values, like
  ? ? ? ? ? o $current_date
  ? ? ? ? ? o $current_time
 
  Some of this is still being finalised, but the general syntax will
 look
  like Xpath and the object model will be what you would expect from
 that.
 
  - thomas
 
  On 10/03/2011 15:48, Bert Verhees wrote:
  Hi,
 
  I am sorry, but I am to busy to read all the discussions on future
  ADL-versions.
  So, now I have a small question, which possible is already
 explained,
 
  Is it possible to write conditional constraints in future ADL?
 
  The question is about implementing care-protocol into an archetype.
 
  For example, if blood-pressure is ?200, force to use another
 entry, for
  example also look at heartbeat
 
  Is there any idea when this new specifications will be in final
 version?
 
  Thanks
  Bert
 
 
 
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
  *
  *
 
 
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
  ___
  openEHR-technical mailing list
  openEHR-technical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
 
 
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

C_DATE_TIME and RM instances

[Heath Frankel]

 

Thomas,


value xsi:type=DV_DATE_TIME
  value2011-03-18/value
/value


this is illegal in ISO 8601 (and therefore openEHR)

[HKF: ] This is actually legal in openEHR as it is also in HL7 V2 (well the
non-extended 20110318 is legal), it is a documented variation of ISO-8601.


and

value xsi:type=DV_DATE_TIME
  value11:01:28/value
/value


also illegal.



[HKF: ] Yep, this is illegal





 Heath

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