You are talking about a future reuse or validation of the data. But what it
was discused here is how to define the reference ranges for any data to
take an action at the moment of data registry. And, as Gerard said, those
references must be stored for future interpretation of the data. Thus, I'm
of the opinion that ideally this should be stored together with the
archetype/templates as it is part of the domain knowledge at that moment.
If it changes, the archetype version might also change as usual. For simple
rules, problably the current rules that can be added to the archetypes
could be enough. But if they are complex and we need to implement them in
an external service, then we have to maintain them functional in the
future. It is exactly the same as with terminologies: they evolve, but we
should mantain past version to interpret old data.

BTW, for our beloved Blood Pressure archetype this has just happened. BP is
still the best example for everything :D
http://www.acc.org/latest-in-cardiology/articles/2017/11/08/11/47/mon-5pm-bp-guideline-aha-2017

2018-03-02 9:47 GMT+01:00 Diego Boscá <yamp...@gmail.com>:

> Not sure if I fully understand/agree. As knowledge advances, past data
> could be seen under a new light (e.g. some medication was given to a set of
> patients and now we know it has a contraindication with another medication)
> and we could get different results each time we run the query, which is
> exactly what we want
>
> 2018-03-02 2:55 GMT+01:00 Colin Sutton <colin.sut...@ctc.usyd.edu.au>:
>
>> 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 <bert.verh...@rosa.nl> 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=oeSX2qbCWwprcB5eNMB
>> 27oRdY2Loky0QJHUrFju91A&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
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ>
>
> [image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
> <https://htmlsig.com/t/000001C4DPJG> [image: Maps]
> <https://htmlsig.com/t/000001BZTWS7>
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to