Smaller pieces, although scrolling would be cool. Cheers Sam Dr Sam Heard FRACGP, MRCGP, DRCOG, FACHI Chairman, Ocean Informatics Chairman, openEHR Foundation Chairman, NTGPE +61417838808 ________________________________ From: Randolph Neall<mailto:randy.ne...@veriquant.com> Sent: ?18/?04/?2013 3:18 AM To: For openEHR technical discussions<mailto:openehr-technical at lists.openehr.org> Subject: Re: Trying to understand the openEHR Information Model
>The performance is perfectly adequate in all of these systems for the kinds of queries used in point of care (e.g. typically sub 1-second), and in some cases where ETL is implemented, the performance is also acceptable. It's also true that quite a lot of effort and thinking has gone into optimising AQL queries. There is always a query that can be written that will take a long time to answer, but so far there is no overlap between those type of queries and point of care latency requirements i.e. such queries are always report-oriented, research queries or some other kind of population query, where a (let's say) 5 second response is perfectly acceptable. That's excellent! Can you give any idea how long it takes to retrieve into live memory and screen on a user's computer an entire EHR record of "typical" size and complexity? Or does that not generally happen, with records instead being fetched in smaller pieces? Randy On Wed, Apr 17, 2013 at 12:10 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > > I should probably point out that there are some dozens of openEHR > operational > deployments<http://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities>, > all heavily using AQL for screen population, reporting and so on. The > performance is perfectly adequate in all of these systems for the kinds of > queries used in point of care (e.g. typically sub 1-second), and in some > cases where ETL is implemented, the performance is also acceptable. It's > also true that quite a lot of effort and thinking has gone into optimising > AQL queries. There is always a query that can be written that will take a > long time to answer, but so far there is no overlap between those type of > queries and point of care latency requirements i.e. such queries are always > report-oriented, research queries or some other kind of population query, > where a (let's say) 5 second response is perfectly acceptable. > > There is probably about 3 years of experience of such systems now (there's > more like 6 years experience of commercially deployed AQL) that show that > the performance challenges of this kind of framework are satisfiable, and > no longer a research question (they were once obviously!). > > The second order types of structures I mentioned below rely less on AQL, > and more on smart commit type rules / triggers logic, which effectively > enables pre-built query results to be maintained in a live system. > > We're somewhere on a road where we are already riding in motorised > transport, but we don't really know if what we have today is a Fiat Punto > or a Maserati. Hopefully it's the Fiat, because that leaves us a lot of fun > and room to get to the Maserati (at which point we start looking at air > travel;-). > > - thomas > > > On 17/04/2013 15:58, Randolph Neall wrote: > > Hi Seref, > > >Hint: think about how you're going to get data out before thinking how > you're supposed to keep it. There are lots of possibilities, but you need > to anchor those with a single method of access. I suggest a brief look at > Archetype Query Language (AQL) > > That's the whole point, Seref--"how you're going to get the data out." > And certainly AQL is one way to do that. My concern has to do with querying > performance (deserialization as a prerequisite to record inspection, etc.) > and the infrastructure resources necessary to support them. Thomas hints at > possibly some big changes when he said, "There is an emerging set of > 'second order' object definitions, that use the URI-based referencing > approach in very sophisticate ways to represent things like care plans, > medication histories and so on. I can't point to a spec right now, but they > will start to appear." I don't know how radical that will prove to be. I'd > assume they'd still occur within the AQL paradigm. But it does appear that > openEHR itself is evolving on this point and perhaps for good reason. > > Please don't interpret my remarks as any sort of disrespect for openEHR; > I hope it has been apparent that my respect for the entire system has grown > as I have learned more about it. Some really brilliant people, perhaps > including you, put this whole thing together. And you all do the whole > world a favor by make it all open and by making yourselves available for > the sort of questions I have raised. > > Randy > > > > * * > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130418/52424454/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
