Rafal We have seen this coming for some time and I would point out a few things that seem clear:
1. That queries can be based across a number of EHRs or within one - the oprimisation issues are somewhat different 2. That queries may return rows of data (like in current RDBS) or lumps of data for viewing - 'data queries' or 'clinical queries' 3. Within each EHR the query may be limited to a specific composition (transaction) type (ie and archetyped transaction) 4. Within transactions the query may be limited to specific organisers All of these queries outlined to this point will return disparate data (even if they are all entries) and will be very difficult to process - very useful clinically. Examples are: What examinations have been done in antenatal attendances What therapies have been planned or implemented for people in outpatients in the last week Then we have queries that get to the data level - these will need to return known data points in the entries. These will be accessed via paths. When building these queries the enquirer will be asked which archetypes and which paths (design time or run time) to return. This would enable us to get a row of data such as: For all patients who have had their blood pressure measured in antenatal clinic - return the systolic and diastolic blood pressures and their weight. For all patients who are on beclomethasone inhalers return the name and dose of inhaled steroid and their peak flow measurements for the past year. You will see that until the query addresses and entry archetype (like a table in RDBS) you will only return information that is clinically readable but difficult to process. The entries then become the equivalent of the tables - the paths are the equivalent of the columns. Some efficiencies come from running queries on one patient - when the query engine can use the archetypes in that EHR as the set of archetypes on which to query - you don't have to look if they are not there. Also, archetypes become the bases of indexes. Cheers, Sam > -----Original Message----- > From: owner-openehr-technical at openehr.org > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale > Sent: Sunday, 23 March 2003 11:24 PM > To: Rafal Szczesniak > Cc: openehr-technical at openehr.org > Subject: Re: Introducing myself + question > > > if you are thinking of specific querying language - I would agree - we > can already see that the use of archetypes at runtime changes how > queries are written and does require some new kind of language. We have > been experimenting on this, and are working on it... > > > - thomas beale > > > Rafal Szczesniak wrote: > > >On Sun, Mar 23, 2003 at 02:56:40PM +1000, Thomas Beale wrote: > > > > > >>Another issue which I think is more important than language is runtime > >>interfaces. Components written in many languages can be interfaced by > >>COM, and presumbly, .Net infrastructure; most languages can > produce DLLs > >>for Windows and .so or other kinds of libraries for the unixes. The > >>ability to interface trusted components is key to building > large systems > >>without having to do everything yourself. > >> > >> > > > >Another interesting thing is that developing openEHR systems might > >reveal the need of specific language to operate on. Similiar > >to what SQL is for relational databases today. This could be also > >a mean to standarise communication between EHR systems. > > > > > >cheers, > > > > > > -- > .............................................................. > Deep Thought Informatics Pty Ltd > mailto:thomas at deepthought.com.au > > openEHR - http://www.openEHR.org > Archetypes - http://www.deepthought.com.au/it/archetypes.html > Community Informatics - http://www.deepthought.com.au/ci/rii/Output/mainTOC.html .............................................................. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
