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" < [email protected]> 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
