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á <[email protected]> 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" <serefarikan@ > kurumsalteknoloji.com> escribió: > >> Hi Colin, >> See responses inline please >> >> On Thu, Mar 1, 2018 at 10:20 AM, Colin Sutton < >> [email protected]> wrote: >> >>> >>> >>> On 1 Mar 2018, at 1:59 am, Seref Arikan <serefarikan@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. >>> >> 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 >>> [email protected] >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >>> lists.openehr.org >>> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org >> > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
