Re: Setting thresholds

[Colin Sutton]

There is a risk that the external service could provide different answers at 
different times, if the external service is updated for technical or clinical 
reasons (e.g. knowledge improvements)
Shouldn't the result of the query to the external service be made at the time 
of the source event, not in AQL.
—
Colin
> On 1 Mar 2018, at 10:31 pm, Bert Verhees  wrote:
> 
> On 01-03-18 12:01, Diego Boscá wrote:
>> I believe that we need a way in standard AQL to call to arbitrary external 
>> services, this seems like another use case for that \
> 
> I agree!
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://scanmail.trustwave.com/?c=13000&d=oeSX2qbCWwprcB5eNMB27oRdY2Loky0QJHUrFju91A&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-technical%5flists%2eopenehr%2eorg


#
Scanned by the Trustwave Secure Email Gateway - Trustwave's comprehensive email 
content security solution. 
#


IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be 
read or used by the named addressee. It is confidential and may contain legally 
privileged information. No confidentiality or privilege is waived or lost by 
any mistaken transmission to you. The CTC is not responsible for any 
unauthorised alterations to this e-mail or attachment to it. Views expressed in 
this message are those of the individual sender, and are not necessarily the 
views of the CTC. If you receive this e-mail in error, please immediately 
delete it and notify the sender. You must not disclose, copy or use any part of 
this e-mail if you are not the intended recipient.

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

Improving the specification for DV_PARSABLE, specially for ACTIVITY.timing

[Pablo Pazos]

Hi all,

The specs have a very loose definition of DV_PARSABLE that makes it hard
for developers to know how to use it correctly.

The first issue is on the DV_PARSABLE.formalism attribute.


*1) In the data_types spec there is no clear terminology associated with
the formalism.*

Current: "Name of the formalism, e.g. GLIF 1.0 , Proforma etc." [1]

Expected: An internal terminology, or references to acceptable external
terminologies, like IANA Media Types [2], or subsets of such external
terminologies (not all IANA Media Types should be considered as
DV_PARSABLE, for instance the binary ones like images, audio, etc.)


[1]
http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_parsable_class
[2] https://www.iana.org/assignments/media-types/media-types.xhtml


*2) In the ehr spec, ACTIVITY.timing is DV_PARSABLE, again the formalism
has a loose definition.*

Current: "Timing of the activity, in the form of a parsable string, such as
an HL7 GTS or ISO8601 string." [3]

Expected: specify a terminology of acceptable codes for the formalism of
timing expressions. Should we consider "HL7 GTS" and "ISO8601" as valid
codes for the formalism attribute?


[3]
http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_activity_class


*3. DV_PARSABLE.formalism is String [4], not DV_CODED_TEXT.*

This generates an interoperability problem, since each implementation is
free of putting virtually anything on the formalism making it almost
impossible for an external system, receiving this data, to correctly parse
the DV_PARSABLE value.

IMO we need to analyze the change on the SEC, and release an ITS for the
correct usage of the formalism if it is String (applies to current and
previous versions of the spec) and if that changes to DV_CODED_TEXT, also
create a guide for that.

This comes from real customers trying to implement this and sending
anything on the formalism.


[4]
http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_parsable_class


*4. Trying to avoid accepting "anything" on the formalism*

What I did on the EHRServer is to validate the formalism values from the
XSD, basically defining my own terminology of accepted values for the
formalism, some IANA for known parsable object representations, and some
specific for the ACTIVITY.timing.

For the ACTIVITY.timing I'm inclined to include FHIR_GTS_ABBREVIATION [5]
and FHIR_TIMING_EVENT [6]


[5] https://www.hl7.org/fhir/valueset-timing-abbreviation.html
[6] https://www.hl7.org/fhir/valueset-event-timing.html


This is my solution:


  
   

 
 

 
 

  

  
  
  
  
  
  
  
  
  

  


   
  
 



*5. The format for DV_PARSABLE.value when using serialization formats,
should be defined based on the formalism.*

When an instance of a COMPOSITION is serialized to XML or JSON, the
contents from DV_PARSABLE.value should be processed in such way that don't
break the serialization format. For instance, if the DV_PARSABLE.formalism
is XML or HTML and the serialization format is XML, just putting the value
as XML or HTML will break the whole COMPOSITION XML.

Currently we don't have an ITS guide that says how to do that correctly.
The poor man solution is to always encode the value in base64, but that
generates an interoperability problem, since there is no place on the
DV_PARSABLE to specify that the value is base64 encoded.

In HL7 there is the ED (encapsulated data) datatype that is similar to the
openEHR DV_ENCAPSULATED, but HL7 ED [7] has the encoding attribute that can
be used to say "this is base64 encoded" [8]. I think we don't have
something similar, and maybe we should.


[7]
http://hl7-definition.caristix.com:9010/Default.aspx?version=HL7%20v2.5.1&dataType=ED
[8]
http://hl7-definition.caristix.com:9010/Default.aspx?version=HL7%20v2.5.1&table=0299


There are a couple of related CRs on JIRA

https://openehr.atlassian.net/browse/SPECPR-242
https://openehr.atlassian.net/browse/SPECPR-126



Anyone else has problems with this area of the specs? How did you solve
that?

-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-t

Re: Setting thresholds

[Thomas Beale]

Sorry - didn't mean to be cryptic.
BFO = basic formal ontology - probably best mainstream reference is the 
book, see here on Amazon 

RO = relations ontology - an ontology of possible relationships between 
upper-level biomedical entities, including part-of, develops-from etc. 
OBO ref .
IAO = Information Artefact Ontology. OBO ref 
.


I'm not saying that the concrete representation of reference data has to 
be an ontology (e.g. as produced by Protege), but reference information 
('knowledge') is unavoidably based on an ontological viewpoint in the 
same way that the contents of SNOMED CT are (should be). Drug data for 
example takes the form of facts about drugs such as constituents, 
interactions; units information is /should be based on an ontology of 
measurement concepts (which is not very well represented in OBO right 
now - as far as I can determine, people think it should be in IAO, but I 
think that is incorrect. Practically, UCUM serves pretty well.)


- thomas

On 01/03/2018 14:50, GF wrote:

The metadata describing these interfaces with these services can be constructed 
using archetypes resulting in Template/Compositions.

Thomas: I know what BFO is.
But what stand RO ans IAO for?

Why must they be based on an ontology?
In the case of signalling/normal values, it will be simple: item-ID, Low value 
plus units, High value plus units, date of publication.



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

[Seref Arikan]

Hi Tom,

On Thu, Mar 1, 2018 at 2:33 PM, Thomas Beale 
wrote:

>
> On 01/03/2018 11:05, Seref Arikan wrote:
>
>> Hi Diego,
>>
>> I'd like to hear how you'd address the requirement via a call to an
>> external service.
>>
>>
> I don't think it should be that complicated - after all, a call out to a
> terminology service is already a call out to a service; terminology is just
> one kind of reference knowledge that a query language / engine needs to get
> at; we can assume that a units service (as Bert and others were discussing
> earlier), lab results reference ranges, drug DB and so on may all be needed
> by the query service.
>

In case I gave the wrong impression: my question above was not meant to
sound like I thought this would be a difficult thing. Reading it again, I
can see that it may be interpreted as 'I'd like to see you try', which was
not the intention. I genuinely wanted to  know how Diego would like to use
AQL to address this specific requirement.

>
> So I think it mainly comes down to the syntax and programming model of
> talking out to such interfaces. We might potentially assume that they are
> all based on a common ontology meta-model of some kind (e.g. based on BFO,
> RO, IAO etc) in which case a common underlying style could be established.


The way I see it, your suggestion may pave the way to the can of worms I
mentioned earlier, so I'll give up on my efforts to not to hijack this
thread :)

Re extending AQL for calls to external services: I'd be inclined to keep
the syntax in the scope of the AQL specification and leave the programming
model out of scope.

I think AQL needs to support procedural extensions as an umbrella concept,
which, then, can be used for a number of things, some of which may be calls
to external knowledge services.

There is a lot more than calling out to external terminology services that
can be accomplished with procedural extensions: they could turn AQL into
the ultimate clinical data query language, which is the upside.

But there is a downside as well: things may get complicated from a
standardisation point of view.  Once calls to external services become part
of syntax, AQL's vendor/implementation independent nature will be harder to
preserve, as vendors start doing useful and no doubt clever things with
calls to external services. Aql's behaviour is already slightly different
across vendors, so if vendor X implements a smart feature using an external
service and that service is available only in my vendor X's implementation,
behaviour interoperability provided by AQL would be damaged.

I think the upsides are worth adding this support but downsides will need
careful management, probably based on profiles/levels etc.

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

Re: Setting thresholds

[GF]

The metadata describing these interfaces with these services can be constructed 
using archetypes resulting in Template/Compositions.

Thomas: I know what BFO is.
But what stand RO ans IAO for?

Why must they be based on an ontology?
In the case of signalling/normal values, it will be simple: item-ID, Low value 
plus units, High value plus units, date of publication.

Gerard Freriks
+31 620347088
gf...@luna.nl

> On 01 Mar 2018, at 15:33, Thomas Beale  wrote:
> 
> 
> On 01/03/2018 11:05, Seref Arikan wrote:
>> Hi Diego,
>> 
>> I'd like to hear how you'd address the requirement via a call to an external 
>> service.
>> 
> 
> I don't think it should be that complicated - after all, a call out to a 
> terminology service is already a call out to a service; terminology is just 
> one kind of reference knowledge that a query language / engine needs to get 
> at; we can assume that a units service (as Bert and others were discussing 
> earlier), lab results reference ranges, drug DB and so on may all be needed 
> by the query service.
> 
> So I think it mainly comes down to the syntax and programming model of 
> talking out to such interfaces. We might potentially assume that they are all 
> based on a common ontology meta-model of some kind (e.g. based on BFO, RO, 
> IAO etc) in which case a common underlying style could be established.
> 
> - thomas
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


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

Re: Setting thresholds

[Thomas Beale]

On 01/03/2018 11:05, Seref Arikan wrote:

Hi Diego,

I'd like to hear how you'd address the requirement via a call to an 
external service.




I don't think it should be that complicated - after all, a call out to a 
terminology service is already a call out to a service; terminology is 
just one kind of reference knowledge that a query language / engine 
needs to get at; we can assume that a units service (as Bert and others 
were discussing earlier), lab results reference ranges, drug DB and so 
on may all be needed by the query service.


So I think it mainly comes down to the syntax and programming model of 
talking out to such interfaces. We might potentially assume that they 
are all based on a common ontology meta-model of some kind (e.g. based 
on BFO, RO, IAO etc) in which case a common underlying style could be 
established.


- thomas


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

Re: Setting thresholds

[GF]

Yes, there might be a need for a service as external point of reference.
In spite of this data in the EHR needs to be suplemented with the actual 
reference ranges as provided by the service.
When we can agree that EHR systems in the future store not only the datapoints 
but the context info as well, then archetypes need to be able to store next to 
the datapoint the reference ranges as occured at the time of committing.
The additional services, most likely, will be part of the system, under the 
application control.

Gerard Freriks
+31 620347088
gf...@luna.nl

> On 01 Mar 2018, at 12:12, Diego Boscá  wrote:
> 
> Assuming there is a service that provides the given value for a given 
> identified range (based on the parameters you provide like sex, age, race... 
> ) it would be allowing kind of namespaces that have defined operations. This 
> would also allow easy querying of external terminologies, public health 
> queries (average/max/min of X in population that has Y, Z, W properties), 
> etc. 
> 
> El 1 mar. 2018 12:06 p. m., "Seref Arikan"  > escribió:
> Hi Diego, 
> 
> I'd like to hear how you'd address the requirement via a call to an external 
> service. 
> 
> I've been holding back on the recent external service calls discussions :) 
> there is certainly a need for that but it also has the potential to open a 
> can of worms and I'd better no hijack this thread ;)
> 
> On Thu, Mar 1, 2018 at 11:01 AM, Diego Boscá  > wrote:
> I believe that we need a way in standard AQL to call to arbitrary external 
> services, this seems like another use case for that 
> 
> El 1 mar. 2018 11:46 a. m., "Seref Arikan"  > escribió:
> Hi Colin, 
> See responses inline please
> 
> On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton  > wrote:
> 
> 
>> On 1 Mar 2018, at 1:59 am, Seref Arikan > > wrote:
>> 
>> […]
>> 
>>> 
>>> First: if the threshold is changing with respect to all instances of a 
>>> particular composition (template_id = 'x') , when the change happens, would 
>>> not you have to update reference ranges of the DV_QUANTITY node in all 
>>> composition instances across all EHRs to express the new threshold? That 
>>> is, if you define high systolic blood pressure using a reference value, 
>>> would not you have to update all blood pressure observations when the 
>>> accepted 'high' value (threshold) changes? 
>>> 
>>> Second: Setting the reference value to express a threshold would make it 
>>> impossible to query above/below threshold sets of composition via AQL 
>>> because it'd require a query that uses the WHERE clause as follows:
>>> " WHERE some/path/node1.value > /some/path/node1.reference_range.value" 
>>> (excuse the mock paths) which, as far as I know is not supported by AQL at 
>>> the moment, not even grammar-wise (I may be out of date on this one) 
>>> 
>>> If you keep the reference value at the application level, all you have to 
>>> do is update it without having to touch the existing instances and use AQL 
>>> to select above/below threshold since you can plug the threshold value 
>>> directly into WHER
>> 
>> […]
>  In a clinical trial, the protocol may set thresholds for measurements in one 
> version of the protocol, then change the thresholds in a subsequent version 
> of the protocol. Since a decision may be based on a threshold level, the 
> threshold value needs to be retained along with the measurement for each 
> instance under each protocol. So I think you need a new template for each 
> protocol. 
> Yep, a new template for each protocol would be what I'd consider, as I 
> mentioned in another reply. Based on the information I heard so far regarding 
> the requirements and the specific example you provided here, I'd consider 
> associating thresholds with the identifier+version of the template for the 
> protocol: can you see any problems with this in the context of your specific 
> example? 
> 
> An AQL query on the threshold level will therefore need to have a unique name 
> for each threshold ( not a value of the threshold) in order to retrieve the 
> value used across protocols in the decision, for a simple case where the 
> decision algorithm does not change.
> Such an AQL query would give you the value used for the protocols indeed 
> (though I don't think you'd need a name, why not use the same path across 
> different versions of protocol templates?) . You could then use those values 
> to issue queries to select above/below threshold instances of data. This 
> would be a workaround for the AQL problem I mentioned in my second point 
> above. 
> —
> Colin
> 
> Scanned by Trustwave SEG - Trustwave's comprehensive email content security 
> solution. 
> 
> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to 
> be read or used by the named addressee. It is confidential a

Re: Setting thresholds

[Bert Verhees]

On 01-03-18 12:12, Diego Boscá wrote:
Assuming there is a service that provides the given value for a given 
identified range (based on the parameters you provide like sex, age, 
race... ) it would be allowing kind of namespaces that have defined 
operations. This would also allow easy querying of external 
terminologies, public health queries (average/max/min of X in 
population that has Y, Z, W properties), etc.


Exactly, it could bring in information from external services in the AQL 
query, for example, a SNOMED hierarchy could be used in an AQL query.


Bert

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

Re: Setting thresholds

[Bert Verhees]

On 01-03-18 12:01, Diego Boscá wrote:
I believe that we need a way in standard AQL to call to arbitrary 
external services, this seems like another use case for that \


I agree!

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

Re: Setting thresholds

[Diego Boscá]

Assuming there is a service that provides the given value for a given
identified range (based on the parameters you provide like sex, age,
race... ) it would be allowing kind of namespaces that have defined
operations. This would also allow easy querying of external terminologies,
public health queries (average/max/min of X in population that has Y, Z, W
properties), etc.

El 1 mar. 2018 12:06 p. m., "Seref Arikan" <
serefari...@kurumsalteknoloji.com> escribió:

> Hi Diego,
>
> I'd like to hear how you'd address the requirement via a call to an
> external service.
>
> I've been holding back on the recent external service calls discussions :)
> there is certainly a need for that but it also has the potential to open a
> can of worms and I'd better no hijack this thread ;)
>
> On Thu, Mar 1, 2018 at 11:01 AM, Diego Boscá  wrote:
>
>> I believe that we need a way in standard AQL to call to arbitrary
>> external services, this seems like another use case for that
>>
>> El 1 mar. 2018 11:46 a. m., "Seref Arikan" > .com> escribió:
>>
>>> Hi Colin,
>>> See responses inline please
>>>
>>> On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton <
>>> colin.sut...@ctc.usyd.edu.au> wrote:
>>>


 On 1 Mar 2018, at 1:59 am, Seref Arikan >>> .com> wrote:

 […]

>
>
> First: if the threshold is changing with respect to all instances of a
> particular composition (template_id = 'x') , when the change happens, 
> would
> not you have to update reference ranges of the DV_QUANTITY node in all
> composition instances across all EHRs to express the new threshold? That
> is, if you define high systolic blood pressure using a reference value,
> would not you have to update all blood pressure observations when the
> accepted 'high' value (threshold) changes?
>
> Second: Setting the reference value to express a threshold would make
> it impossible to query above/below threshold sets of composition via AQL
> because it'd require a query that uses the WHERE clause as follows:
> " WHERE some/path/node1.value > 
> /some/path/node1.reference_range.value"
> (excuse the mock paths) which, as far as I know is not supported by AQL at
> the moment, not even grammar-wise (I may be out of date on this one)
>
> If you keep the reference value at the application level, all you have
> to do is update it without having to touch the existing instances and use
> AQL to select above/below threshold since you can plug the threshold value
> directly into WHER
>
> […]
>
  In a clinical trial, the protocol may set thresholds for measurements
 in one version of the protocol, then change the thresholds in a subsequent
 version of the protocol. Since a decision may be based on a threshold
 level, the threshold value needs to be retained along with the measurement
 for each instance under each protocol. So I think you need a new template
 for each protocol.

>>> Yep, a new template for each protocol would be what I'd consider, as I
>>> mentioned in another reply. Based on the information I heard so far
>>> regarding the requirements and the specific example you provided here, I'd
>>> consider associating thresholds with the identifier+version of the template
>>> for the protocol: can you see any problems with this in the context of your
>>> specific example?
>>>

 An AQL query on the threshold level will therefore need to have a
 unique name for each threshold ( not a value of the threshold) in order to
 retrieve the value used across protocols in the decision, for a simple case
 where the decision algorithm does not change.

>>> Such an AQL query would give you the value used for the protocols indeed
>>> (though I don't think you'd need a name, why not use the same path across
>>> different versions of protocol templates?) . You could then use those
>>> values to issue queries to select above/below threshold instances of data.
>>> This would be a workaround for the AQL problem I mentioned in my second
>>> point above.
>>>
 —
 Colin
 --

 Scanned by *Trustwave SEG* - Trustwave's comprehensive email content
 security solution.

 --
 IMPORTANT NOTICE: This e-mail and any attachment to it are intended
 only to be read or used by the named addressee. It is confidential and may
 contain legally privileged information. No confidentiality or privilege is
 waived or lost by any mistaken transmission to you. The CTC is not
 responsible for any unauthorised alterations to this e-mail or attachment
 to it. Views expressed in this message are those of the individual sender,
 and are not necessarily the views of the CTC. If you receive this e-mail in
 error, please immediately delete it and notify the sender. You must not
 disclose, copy or use any part of this e-mail if you ar

Re: Setting thresholds

[Seref Arikan]

Hi Diego,

I'd like to hear how you'd address the requirement via a call to an
external service.

I've been holding back on the recent external service calls discussions :)
there is certainly a need for that but it also has the potential to open a
can of worms and I'd better no hijack this thread ;)

On Thu, Mar 1, 2018 at 11:01 AM, Diego Boscá  wrote:

> I believe that we need a way in standard AQL to call to arbitrary external
> services, this seems like another use case for that
>
> El 1 mar. 2018 11:46 a. m., "Seref Arikan"  kurumsalteknoloji.com> escribió:
>
>> Hi Colin,
>> See responses inline please
>>
>> On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton <
>> colin.sut...@ctc.usyd.edu.au> wrote:
>>
>>>
>>>
>>> On 1 Mar 2018, at 1:59 am, Seref Arikan >> .com> wrote:
>>>
>>> […]
>>>


 First: if the threshold is changing with respect to all instances of a
 particular composition (template_id = 'x') , when the change happens, would
 not you have to update reference ranges of the DV_QUANTITY node in all
 composition instances across all EHRs to express the new threshold? That
 is, if you define high systolic blood pressure using a reference value,
 would not you have to update all blood pressure observations when the
 accepted 'high' value (threshold) changes?

 Second: Setting the reference value to express a threshold would make
 it impossible to query above/below threshold sets of composition via AQL
 because it'd require a query that uses the WHERE clause as follows:
 " WHERE some/path/node1.value > /some/path/node1.reference_range.value"
 (excuse the mock paths) which, as far as I know is not supported by AQL at
 the moment, not even grammar-wise (I may be out of date on this one)

 If you keep the reference value at the application level, all you have
 to do is update it without having to touch the existing instances and use
 AQL to select above/below threshold since you can plug the threshold value
 directly into WHER

 […]

>>>  In a clinical trial, the protocol may set thresholds for measurements
>>> in one version of the protocol, then change the thresholds in a subsequent
>>> version of the protocol. Since a decision may be based on a threshold
>>> level, the threshold value needs to be retained along with the measurement
>>> for each instance under each protocol. So I think you need a new template
>>> for each protocol.
>>>
>> Yep, a new template for each protocol would be what I'd consider, as I
>> mentioned in another reply. Based on the information I heard so far
>> regarding the requirements and the specific example you provided here, I'd
>> consider associating thresholds with the identifier+version of the template
>> for the protocol: can you see any problems with this in the context of your
>> specific example?
>>
>>>
>>> An AQL query on the threshold level will therefore need to have a unique
>>> name for each threshold ( not a value of the threshold) in order to
>>> retrieve the value used across protocols in the decision, for a simple case
>>> where the decision algorithm does not change.
>>>
>> Such an AQL query would give you the value used for the protocols indeed
>> (though I don't think you'd need a name, why not use the same path across
>> different versions of protocol templates?) . You could then use those
>> values to issue queries to select above/below threshold instances of data.
>> This would be a workaround for the AQL problem I mentioned in my second
>> point above.
>>
>>> —
>>> Colin
>>> --
>>>
>>> Scanned by *Trustwave SEG* - Trustwave's comprehensive email content
>>> security solution.
>>>
>>> --
>>> IMPORTANT NOTICE: This e-mail and any attachment to it are intended
>>> only to be read or used by the named addressee. It is confidential and may
>>> contain legally privileged information. No confidentiality or privilege is
>>> waived or lost by any mistaken transmission to you. The CTC is not
>>> responsible for any unauthorised alterations to this e-mail or attachment
>>> to it. Views expressed in this message are those of the individual sender,
>>> and are not necessarily the views of the CTC. If you receive this e-mail in
>>> error, please immediately delete it and notify the sender. You must not
>>> disclose, copy or use any part of this e-mail if you are not the intended
>>> recipient.
>>> --
>>>
>>> ___
>>> 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
>>
>
> ___
> openEH

Re: Setting thresholds

[Diego Boscá]

I believe that we need a way in standard AQL to call to arbitrary external
services, this seems like another use case for that

El 1 mar. 2018 11:46 a. m., "Seref Arikan" <
serefari...@kurumsalteknoloji.com> escribió:

> Hi Colin,
> See responses inline please
>
> On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton <
> colin.sut...@ctc.usyd.edu.au> wrote:
>
>>
>>
>> On 1 Mar 2018, at 1:59 am, Seref Arikan > .com> wrote:
>>
>> […]
>>
>>>
>>>
>>> First: if the threshold is changing with respect to all instances of a
>>> particular composition (template_id = 'x') , when the change happens, would
>>> not you have to update reference ranges of the DV_QUANTITY node in all
>>> composition instances across all EHRs to express the new threshold? That
>>> is, if you define high systolic blood pressure using a reference value,
>>> would not you have to update all blood pressure observations when the
>>> accepted 'high' value (threshold) changes?
>>>
>>> Second: Setting the reference value to express a threshold would make it
>>> impossible to query above/below threshold sets of composition via AQL
>>> because it'd require a query that uses the WHERE clause as follows:
>>> " WHERE some/path/node1.value > /some/path/node1.reference_range.value"
>>> (excuse the mock paths) which, as far as I know is not supported by AQL at
>>> the moment, not even grammar-wise (I may be out of date on this one)
>>>
>>> If you keep the reference value at the application level, all you have
>>> to do is update it without having to touch the existing instances and use
>>> AQL to select above/below threshold since you can plug the threshold value
>>> directly into WHER
>>>
>>> […]
>>>
>>  In a clinical trial, the protocol may set thresholds for measurements in
>> one version of the protocol, then change the thresholds in a subsequent
>> version of the protocol. Since a decision may be based on a threshold
>> level, the threshold value needs to be retained along with the measurement
>> for each instance under each protocol. So I think you need a new template
>> for each protocol.
>>
> Yep, a new template for each protocol would be what I'd consider, as I
> mentioned in another reply. Based on the information I heard so far
> regarding the requirements and the specific example you provided here, I'd
> consider associating thresholds with the identifier+version of the template
> for the protocol: can you see any problems with this in the context of your
> specific example?
>
>>
>> An AQL query on the threshold level will therefore need to have a unique
>> name for each threshold ( not a value of the threshold) in order to
>> retrieve the value used across protocols in the decision, for a simple case
>> where the decision algorithm does not change.
>>
> Such an AQL query would give you the value used for the protocols indeed
> (though I don't think you'd need a name, why not use the same path across
> different versions of protocol templates?) . You could then use those
> values to issue queries to select above/below threshold instances of data.
> This would be a workaround for the AQL problem I mentioned in my second
> point above.
>
>> —
>> Colin
>> --
>>
>> Scanned by *Trustwave SEG* - Trustwave's comprehensive email content
>> security solution.
>>
>> --
>> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only
>> to be read or used by the named addressee. It is confidential and may
>> contain legally privileged information. No confidentiality or privilege is
>> waived or lost by any mistaken transmission to you. The CTC is not
>> responsible for any unauthorised alterations to this e-mail or attachment
>> to it. Views expressed in this message are those of the individual sender,
>> and are not necessarily the views of the CTC. If you receive this e-mail in
>> error, please immediately delete it and notify the sender. You must not
>> disclose, copy or use any part of this e-mail if you are not the intended
>> recipient.
>> --
>>
>> ___
>> 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: Setting thresholds

[Seref Arikan]

Hi Colin,
See responses inline please

On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton 
wrote:

>
>
> On 1 Mar 2018, at 1:59 am, Seref Arikan 
> wrote:
>
> […]
>
>>
>>
>> First: if the threshold is changing with respect to all instances of a
>> particular composition (template_id = 'x') , when the change happens, would
>> not you have to update reference ranges of the DV_QUANTITY node in all
>> composition instances across all EHRs to express the new threshold? That
>> is, if you define high systolic blood pressure using a reference value,
>> would not you have to update all blood pressure observations when the
>> accepted 'high' value (threshold) changes?
>>
>> Second: Setting the reference value to express a threshold would make it
>> impossible to query above/below threshold sets of composition via AQL
>> because it'd require a query that uses the WHERE clause as follows:
>> " WHERE some/path/node1.value > /some/path/node1.reference_range.value"
>> (excuse the mock paths) which, as far as I know is not supported by AQL at
>> the moment, not even grammar-wise (I may be out of date on this one)
>>
>> If you keep the reference value at the application level, all you have to
>> do is update it without having to touch the existing instances and use AQL
>> to select above/below threshold since you can plug the threshold value
>> directly into WHER
>>
>> […]
>>
>  In a clinical trial, the protocol may set thresholds for measurements in
> one version of the protocol, then change the thresholds in a subsequent
> version of the protocol. Since a decision may be based on a threshold
> level, the threshold value needs to be retained along with the measurement
> for each instance under each protocol. So I think you need a new template
> for each protocol.
>
Yep, a new template for each protocol would be what I'd consider, as I
mentioned in another reply. Based on the information I heard so far
regarding the requirements and the specific example you provided here, I'd
consider associating thresholds with the identifier+version of the template
for the protocol: can you see any problems with this in the context of your
specific example?

>
> An AQL query on the threshold level will therefore need to have a unique
> name for each threshold ( not a value of the threshold) in order to
> retrieve the value used across protocols in the decision, for a simple case
> where the decision algorithm does not change.
>
Such an AQL query would give you the value used for the protocols indeed
(though I don't think you'd need a name, why not use the same path across
different versions of protocol templates?) . You could then use those
values to issue queries to select above/below threshold instances of data.
This would be a workaround for the AQL problem I mentioned in my second
point above.

> —
> Colin
> --
>
> Scanned by *Trustwave SEG* - Trustwave's comprehensive email content
> security solution.
>
> --
> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only
> to be read or used by the named addressee. It is confidential and may
> contain legally privileged information. No confidentiality or privilege is
> waived or lost by any mistaken transmission to you. The CTC is not
> responsible for any unauthorised alterations to this e-mail or attachment
> to it. Views expressed in this message are those of the individual sender,
> and are not necessarily the views of the CTC. If you receive this e-mail in
> error, please immediately delete it and notify the sender. You must not
> disclose, copy or use any part of this e-mail if you are not the intended
> recipient.
> --
>
> ___
> 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: Setting thresholds

[Colin Sutton]

On 1 Mar 2018, at 1:59 am, Seref Arikan 
mailto:serefari...@kurumsalteknoloji.com>> 
wrote:

[…]


First: if the threshold is changing with respect to all instances of a 
particular composition (template_id = 'x') , when the change happens, would not 
you have to update reference ranges of the DV_QUANTITY node in all composition 
instances across all EHRs to express the new threshold? That is, if you define 
high systolic blood pressure using a reference value, would not you have to 
update all blood pressure observations when the accepted 'high' value 
(threshold) changes?

Second: Setting the reference value to express a threshold would make it 
impossible to query above/below threshold sets of composition via AQL because 
it'd require a query that uses the WHERE clause as follows:
" WHERE some/path/node1.value > /some/path/node1.reference_range.value" 
(excuse the mock paths) which, as far as I know is not supported by AQL at the 
moment, not even grammar-wise (I may be out of date on this one)

If you keep the reference value at the application level, all you have to do is 
update it without having to touch the existing instances and use AQL to select 
above/below threshold since you can plug the threshold value directly into WHER
[…]
 In a clinical trial, the protocol may set thresholds for measurements in one 
version of the protocol, then change the thresholds in a subsequent version of 
the protocol. Since a decision may be based on a threshold level, the threshold 
value needs to be retained along with the measurement for each instance under 
each protocol. So I think you need a new template for each protocol.

An AQL query on the threshold level will therefore need to have a unique name 
for each threshold ( not a value of the threshold) in order to retrieve the 
value used across protocols in the decision, for a simple case where the 
decision algorithm does not change.
—
Colin

#
Scanned by the Trustwave Secure Email Gateway - Trustwave's comprehensive email 
content security solution. 
#


IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be 
read or used by the named addressee. It is confidential and may contain legally 
privileged information. No confidentiality or privilege is waived or lost by 
any mistaken transmission to you. The CTC is not responsible for any 
unauthorised alterations to this e-mail or attachment to it. Views expressed in 
this message are those of the individual sender, and are not necessarily the 
views of the CTC. If you receive this e-mail in error, please immediately 
delete it and notify the sender. You must not disclose, copy or use any part of 
this e-mail if you are not the intended recipient.

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