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