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" < [email protected]> 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á <[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 >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
