SV: SV: Usage of Compositoin.Category

2016-03-15 Thread Bjørn Næss 
The problem is not to filter in data. The most important feature to support is 
to filter out data. 
The proposed solution is to add a new category code to add a new group of 
Compositions which by default is sorted out. 
This could be done by archetypes. But that creates the need for the 
implementations to add new filters as new archetypes are developed. If we agree 
that there is a large group of "report" compositions with only referred data 
from their primary sources - then we should make this a first class citizen of 
the openEHR domain model. 

The discussions about links: 
Yes we could use links. But where should we add the links? From my point of 
view the only place to add these lnks would be on the composition root. But 
then you miss the opportunity to add relationship between links. And there is a 
large group of archetyped compositions that is added into to EHR , but they are 
transported to another system on some other information model (HL7, EDIFACT, 
PDF, Paper, etc.). The simple idea behind this proposal is to define a generic 
system to create openEHR compositions that is the primary source for all this 
kind of messages. The only needed thing is to either use TDD or some other 
transformation of a "compiled" composition.  As far as I can see now this is 
the simplest and most efficient way to handle this. Then the content may be 
archetyped and the transformation could work directly on the RM model to create 
the expected outcome.


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

Mobil +47 93 43 29 10


-Opprinnelig melding-
Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: fredag 11. mars 2016 14.12
Til: openehr-technical@lists.openehr.org
Emne: Re: SV: Usage of Compositoin.Category


Currently I think we filter on 'report' COMPOSITIONs via something like:

FROM COMPOSITION c[openEHR-EHR-COMPOSITION.report.v1]
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.body_weight.v1]

So that would not need any change to the COMPOSITION.category to be achieved. 
Not saying there are not reasons to do it, just that the normal way today seems 
to satisfy the requirement.

Secondly, just a mechanical AQL thing: it should normally be possible to do:

WHERE c/category/defining_code matches {[openehr::434]}

- thomas

On 10/03/2016 12:32, Bjørn Næss wrote:
> Hi Ian
> Great response.
>
> The most important thing for me is to precisely define the semantic meaning 
> of the content in a composition. In this specific use-case the content of the 
> composition is always a copy of the primary source.
> This means that the Discharge letter only bring one new thing into the EHR - 
> that is the fact that there is an approved discharge letter. But the entries 
> in the composition is link and copies of entries in other primary sources.
>
> The requirements to the system is quite small:
>
> * Content of "report" documents MUST not be in the resultset when doing 
> normal AQL queries.
> * It MUST be possible to query for "report" compositions with specific 
> content.
>
> The solution to this problem is simple and I can give an example with an AQL 
> query. Below is a standard query for body weight. Look at the WHERE 
> condition. Here I am looking for all body weights which are NOT part of a 
> report composition. This WHERE condition will be the default filter on all 
> queries.
> If the client would like to query for all body weights in report document, 
> then just change from NOT EQUALS 434 to EQUALS 434.
>
>   SELECT 
> o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude
>   FROM COMPOSITION c
>   CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.body_weight.v1]
>   WHERE c/category/defining_code/terminology_id/value = 'openehr'AND 
> c/category/defining_code/code_string != '434'
>
>
> Given that we agree that there is a class of compositions which belongs to 
> the "report" group.
> Then we should add such semantic into the RM to make it precise and 
> consistent.
>
>
> Best regards
> Bjørn Næss
> Product owner
> DIPS ASA
>
> Mobil +47 93 43 29 10
>


___
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

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

2016-03-15 Thread Bjørn Næss 
Yes - there must be some kind of misunderstanding. The intention have never 
been that end-user should do the important and challenging work on developing 
clinicial information models (archetypes). The idea have been that this gives 
the clinical community an opportunity to influent and co-operate in this work.

I think all agree that the development and deployment of ICT solutions for 
healthcare is a large socio-organizational-technical challenge.  The work done 
by domain experts is only a (important and essential) part of that problem 
domain.



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

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: fredag 11. mars 2016 15.16
Til: openehr-clini...@lists.openehr.org; Openehr-Technical 

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


I can only see the abstract for now, but I think the authors seem to have 
developed the misconception that end-users would somehow be designing 
applications. openEHR doesn't try to do that, and it's the first time I've 
heard anyone suggest it. openEHR just enables domain experts (generally = a 
small proportion of healthcare professionals, who might also be some kind of 
system user in some part of the world) to more directly define the information 
content of the system, in such a way that it can be processed and queried on a 
semantic level.

The Business Purpose of Archetypes section in the Archetype Technology Overview 

 may help to show why this is useful and necessary (it's short!).

There are still many other problems to solve such as clinical workflows and 
user interaction / UX.

I am currently at Intermountain Health in Salt Lake City working with the 
Activity Based Design (ABD) group that has developed a new architecture that I 
think has a realistic chance of addressing a) workflow (e.g. typical nursing 
tasks like cannulation; more complex cooperative workflows that involve shared 
care) and b) some aspects of UI interaction within workflows. They are just at 
an early prototype stage, and it has taken nearly 2 years to get to the current 
architecture (naturally taking into account many previous attempts and 
experience).

This effort is the first I have seen that has what I think may be the needed 
theoretical understanding and technical architecture to starting to solve 
clinical process and (some of) UI/UX. And what does it rely on? Formal clinical 
models, and it assumes that those models are created by clinical experts. Not 
only that, it explicitly assumes a 'template' concept of the same kind as 
openEHR's, in order to construct useful data sets.

It considers these 'templates' as the basis of an 'Activity' description, which 
then adds new abilities to blend in some presentation directives, pre- and 
post-conditions, some workflow elements, cost-related items (e.g. ICD coding) 
and so on. The innovation here is to consider an Activity a unit of clinical 
work and to attach these process-related semantics into that level of artefact.

So let's just reflect on the fact that this research is only now emerging from 
one of the leading institutions in the world that has historically specialised 
in workflow and decision support.

openEHR as it is today is just a semantic content + querying platform, and I 
think we can reasonably say that we have some handle on generating 
developer-usable artefacts, i.e. things like TDS, TDO etc, but they are all 
content related. These are starting to be standardised now.

The openEHR of today needs to leverage new work such as ABD (or something like 
it) to achieve many of the things that the Norwegian paper talks about. The 
paper seems to be critiquing a somewhat unrealistic set of expectations re: 
openEHR, although I am sure it has useful lessons.

I'll provide a proper description of ABD ASAP, which I think will provide our 
community (particularly those working on clinical workflow, process etc) new 
ideas on 'the next layer' for openEHR.

- thomas
On 09/03/2016 23:58, Bakke, Silje Ljosland wrote:
Hi everyone!

As some of you may have noticed, a paper called "Evaluating Model-Driven 
Development for large-scale EHRs through the openEHR approach" 
(http://www.sciencedirect.com/science/article/pii/S1386505616300247) was 
recently published by a PhD student at the University of Tromsø. The paper has 
some pretty direct criticism of the ideal of wide clinical engagement in widely 
reusable information models, as well as the clear division between the clinical 
and the technical domain inherent in the openEHR model. I think a lot of the 
observations detailed in the paper are probably correct, for its limited scope 
(one Norwegian region and 4 years of observation, half

RE: rm_type_name for the DV_DURATIONs primitive object in XML

2016-03-15 Thread Sebastian Garde 


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Heath Frankel
Sent: Dienstag, 15. März 2016 21:22
To: For openEHR technical discussions 
Subject: Re: rm_type_name for the DV_DURATIONs primitive object in XML

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

[SG]  CKM is still using the webservice:
The OPT displayed in CKM is retrieved from the TD OPT webservice by sending the 
archetypes in XML.
The XML is generated by the Java XML serialiser, however I postprocess this and 
replace DV_DURATION with DURATION in this case.
The original reason for this was consistency of MD5 Canonical Hash calculation.
(However, I am now able to send the ADL directly to the webservice to calculate 
the hash, which gets around this problem and ensures consistency of the hash 
with TD.
There is (or was) a similar issue for (DV_) date and time elements and some 
other minor issues which made this the more reliable approach.)

But this is why at the moment the Archetype XML in CKM would use DV_DURATION 
while the OPT in CKM would use DURATION - which is clearly insufficient.

Need to think more about the rest below...cheers for now, Sebastian


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

Re: rm_type_name for the DV_DURATIONs primitive object in XML

2016-03-15 Thread 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: rm_type_name for the DV_DURATIONs primitive object in XML

2016-03-15 Thread Boštjan Lah 
Sebastian/Diego,

You're absolutely right - sorry I have been too quick in my reply.

I think what template designer 2.8 (2.6 does the same BTW) does is correct this 
is the same as we always had.

However there is still a bug in CKM opt generation - but for 
INTERVAL what it does there is at the wrong level.

I don't have the new AE which supports INTERVAL so I tried this 
with INTERVAL and I get this:
  
DV_INTERVALDV_DATE_TIME

  true
  true
  false
  false
  1
  1



  upper
  
true
true
false
false
0
1
  
  
DV_DATE_TIME


so INTERVAL.upper is of type DV_DATE_TIME, which is the correct type.

However for INTERVAL I get the following:
  

DV_INTERVALDV_DURATION>

  true
  true
  false
  false
  1
  1



  
upper
  
true
true
false
false
1
1
  
  
DURATION

So here the INTERVAL.upper type is DURATION, which is clearly wrong - it should 
really be DV_DURATION.

Best regards,
Bostjan





On 15 Mar 2016, at 17:01, Diego Boscá 
> wrote:

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

Re: rm_type_name for the DV_DURATIONs primitive object in XML

2016-03-15 Thread Diego Boscá 
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 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

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

Re: rm_type_name for the DV_DURATIONs primitive object in XML

2016-03-15 Thread Diego Boscá 
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.html#_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_1433773264460_352968_7042
> and/or
> http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1422968609347_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.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: rm_type_name for the DV_DURATIONs primitive object in XML

2016-03-15 Thread Boštjan Lah 
Hi,

according to the specs it's String: 
http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_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_1433773264460_352968_7042
 and/or
http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1422968609347_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.openehr.org

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

rm_type_name for the DV_DURATIONs primitive object in XML

2016-03-15 Thread Sebastian Garde 
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_1433773264460_352968_7042
 and/or
http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1422968609347_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.openehr.org

RE: Usage of Compositoin.Category

2016-03-15 Thread Ivar Yrke 
"Preferred" data is a key issue here. I think "preferable" is an aspect of the 
scenario, not of the data itself. Therefore we must be able to be explicit in 
AQLs, so that each scenario can express its preference.

mvh
Ivar Yrke
Senior systemutvikler
DIPS ASA
Telefon +47 75 59 24 06
Mobil +47 90 78 89 33

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: 14. mars 2016 18:50
To: For openEHR technical discussions 
Subject: Re: Usage of Compositoin.Category

Hi Ivar,

I have no issue with the result of link handling in AQL being explicit and 
predictable but I don't think this solves the problem of deciding which is 
'preferred queryable' data. Where an active problem list is maintained, the 
preferred queryable data would, in many implementations (but not all) live at 
the end of a link/reference, rather than being in-line. From a clinical 
perspective, it really does not matter whether the problem list has been 
implemented as an in-line persistent-style composition with entries 'cloned' 
from their original event compositions or whether those original entries are 
simply referenced from the event compositions. I would agree that te latter 
approach is probably more elegant but from a clinical perspective, it is the 
Problem List composition that I choose to use as the preferred query route to 
retrieve problems, how it gets them is really up to the implementer. I would 
like to be able to express AQL statements agnostic to that underlying 
implementation choice.

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 13 March 2016 at 08:20, Ivar Yrke  wrote:
> I said:
>
> "I can see that there possibly are needs for an AQL that resolves links, but 
> I would rather see this as the special case"
>
> which is basically exactly what Thomas says in his rephrasing of my last 
> statement. My key point is that link handling in AQL must be explicit and 
> predictable. Your scenarios illustrate why this is important.
>
> mvh
> Ivar Yrke
> Senior systemutvikler
> DIPS ASA
> Telefon +47 75 59 24 06
> Mobil +47 90 78 89 33
>
> -Original Message-
> From: openEHR-technical 
> [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Ian 
> McNicoll
> Sent: 12. mars 2016 08:41
> To: For openEHR technical discussions 
> 
> Subject: Re: Usage of Compositoin.Category
>
> Hi Ivar,
>
> I'm not sure the situation is quite as clear-cut, in that I donlt think there 
> is necessarilly a simple distinction between primary data which should 
> normally be query-accessible and in-line vs. secondary data which is normally 
> query-inaccessible and referenced.
>
> A few scenarios
>
> 1. Vital signs event - easy!! Primary, in-line and accessible
>
> 2. Diagnosis event. Primary, in-line but depending on whether a secondary 
> problem list is maintained, you may not want to use these original diagnoses 
> events for decision support.
>
> 3. Problem summary. Secondary and definitely need to be query-accessible, but 
> may be in-line or referenced depending on implementation.
>
> 4. Discharge summary. Mostly secondary but may introduce new primary content 
> and again, whether the content is in-lie or referenced is to some extent an 
> implementation decision. DIPS have decided to use referencing, others do not.
>
> 5. End of Life Summary. The critical aspects of this document are primary e.g 
> Resuscitation wishes but other aspects are secondary (though and may be 
> in-line or referenced.
>
> I think the points raised are valid but we may need to tease out several axes 
> here.
>
> 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 11 March 2016 at 09:39, Ivar Yrke  wrote:
>> Hi
>> An interesting discussion that touches the very concept of structured 
>> information, in my opinion. I wonder if the suggested solution looks at the 
>> problem from the best angle. So here is my angle:
>>
>> As a person with some SQL experience I would expect an AQL to return 
>> ONLY primary content unless told otherwise. Any content that lives in 
>> a Composition as a link I would not expect to see in that Composition 
>> as an entry. Resolving links is a task for the level "above"
>> (rendering on a screen etc.). I can see that there possibly are needs 
>> for an AQL that resolves links, but I would