Hi Bruno, > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Bruno Cadonna > Sent: Friday, June 20, 2008 6:54 PM > To: For openEHR technical discussions > Subject: Re: Request: openEHR temporal data instance needed ... > > Hi Chunlan, > > You are right, when you write archetyped data can be used to represent > the data sources/data inputs of my research, but I am not sure about > the retrieval of the data. > > If we look at figure 37 of the openEHR overview document, my research > focus rather on the persistence layer than on the upper layers. I > believe costly computations with very large data -- and I assume EHRs > will contain very large data -- should be done in the persistence layer > using capabilities of the underlying data model and database management > system. I consider my research related to the implementation dependant > part of temporal queries on openEHR data. > > If I understood it right, AQL is a domain specific query interface to > the openEHR system. Looking again on the figure mentioned above and on > the service model definition, it is not clear to me how exactly a query > should be answered:
[Chunlan Ma] AQL is an archetype specific query language. > * Does the query engine chop the query in minimal pieces and mainly > process the data in the application logic layer or > * does the query engine minimally preprocess the query, forward it to > the back-end service layer which forwards it further to the > persistence layer where the query is translated into the native query > language of the database mangement system and executed? The results > would go the inverse way with all needed postprocessing. [Chunlan Ma] An AQL query engine can be implemented in various ways and each approach would have its own pros and cons. For instance, a query engine can be fully independent from persistent layer, but trouble is that the processing speed maybe slow. Your second option would reduce some work load of the query engine and improve the efficiency, but you need to think about how to keep the system maintenance at a low level. No matter how a query engine is implemented and how persistent layer is implemented, the AQL query statement must be the same and the returned result set must be same if the query is executed against same data. At the moment, we haven't done much work on AQL temporal queries. Only at the archetype level, can you please list some of your requirements, i.e. what sorts of data you want to retrieve? Cheers, Chunlan > > I believe the second variant is more efficient than the first, > especially for aggregate queries. > > I hope I did not misunderstand you. > > Cheers > Bruno > > > Chunlan Ma wrote: > > Hi Bruno, > > > > The reason that I believe openEHR architecture ease hierarchical > > temporal data management is because that I think archetypes and > > semantic query language that openEHR offers would smooth the process > > of deploying your temporal data management model. It has nothing to > do > > with the management model development itself. > > > > I guess that your current research is to develop the mathematical > > model dealing with all sort of temporal data. Data quality, data > > representation/data schema, and data retrieval maybe out of your > > research scope. However, these factors have to be taken into account > > when your model is deployed in a real system. > > > > At the moment, I see archetypes is the most flexible and powerful > > technology to represent complicated clinical data, including temporal > > data. Both archetypes and AQL (Archetype Query Language) are > separated > > from system implementation. They are reusable and sharable across > > institutions. They can be used to represent and retireve the data > > sources/data inputs of your model. > > > > Cheers, > > Chunlan > > > > -----Original Message----- > > From: openehr-technical-bounces at openehr.org > > [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Bruno > > Cadonna > > Sent: Thursday, June 19, 2008 4:25 PM > > To: For openEHR technical discussions > > Subject: Re: Request: openEHR temporal data instance needed ... > > > > Hi Chunlan, > > > > I have a question regarding your last post. > > Could you explain why you believe, that openEHR architecture ease > > hierarchical temporal data management? > > > > Cheers > > Bruno > > > > > > Chunlan Ma wrote: > >> Hi Bruno, > >> > >> Your research topic is very interesting and I believe openEHR > >> architecture ease hierarchical temporal data management. I don't > have > >> openEHR data instances which satisfy your requirement. However, if > >> you or anybody have real case scenario, I would be able to generate > >> the > > instances for you. > >> Cheers, > >> > >> Chunlan > >> ---------------------------------------------------------- > >> Dr Chunlan Ma (Med) > >> PhD (Health Informatics) > >> > >> Software Architect, Clinical Interoperability > >> > >> t: +61 (0)8 8223 3075 | m: 0405 139 586 > >> f: +61 (0)8 8223 2570 | skype: chunlan_ma > >> > >> Ocean Informatics Pty Ltd > >> Ground floor, 64 Hindmarsh Square > >> Adelaide SA 5000 > >> > >> http://www.oceaninformatics.com > >> > >> > >> > >> -----Original Message----- > >> From: openehr-technical-bounces at openehr.org > >> [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Bruno > >> Cadonna > >> Sent: Thursday, June 19, 2008 3:20 AM > >> To: For openEHR technical discussions > >> Subject: Re: Request: openEHR temporal data instance needed ... > >> > >> Hi Ian, > >> > >> I am sorry for my explanation being too vague. > >> > >> Temporal data management is a field of data management focusing on > >> the temporal aspect of data. Given temporal data, i.e. data with one > >> or more time dimensions, operations like temporal joins and temporal > >> aggregates are different compared to their counterparts for > >> non-temporal > > data. > >> To make things clearer, the following example describes one type of > >> temporal aggregation called instant temporal aggregation: > >> > >> A patient was prescribed 2 medications. The first medication was > >> prescribed for the interval 0 to 10, the second medication was > >> prescribed for the interval 5 to 15. Assume you want to know how > many > >> medications were prescribed for this patient over time. First, you > >> have to compute time interval for which the data does not change in > time. > >> This operation is called time slicing. In this example the constant > >> intervals after time slicing are: > >> [0, 4] > >> [5, 10] > >> [11, 15] > >> The second step in temporal aggregation is to calculate the > aggregate > >> value > >> -- in this case the number of medications -- for each constant > >> interval, which are: > >> [0, 4], 1 > >> [5, 10], 2 > >> [11, 15], 1 > >> > >> In this example there are only two intervals but there might be a > lot > >> more with much more overlapping sections becoming a challenge > >> regarding computing. Instant temporal aggregation is just one type > of > >> temporal aggregation, there are some more. > >> With relational DBMSs you do temporal aggregation with using > >> complicated SQL queries, however, those are rather inefficient. In > >> the last two decades researchers in temporal data management came up > >> with some temporal data models, temporal operations and > corresponding > >> efficient algorithms, mainly for the relational data model. My > >> research focuses on temporal data management on hierarchical data, > >> like XML. Since I like the openEHR idea and I have worked in Health > >> Informatics for the last years, I would like to use openEHR data > > instances. > >> At the moment I am looking for a sound running example, which is > >> clinically relevant and needs temporal data management. I was > >> thinking about some temporal aggregates over a prescription list, a > >> problem list or some other archetyped data with potentially > >> overlapping time intervals. If somebody has an idea, s/he is really > welcome. > >> > >> I hope things are clearer now. > >> > >> Cheers > >> Bruno > >> > >> > >> _______________________________________________ > >> openEHR-technical mailing list > >> openEHR-technical at openehr.org > >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > -- > > Bruno Cadonna > > Center for Database and Information Systems (DIS) > > Faculty of Computer Science > > Free University of Bozen-Bolzano > > > > Piazza Domenicani 3 > > 39100 Bozen/Bolzano > > Italy > > > > web: http://www.unibz.it/inf > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- > Bruno Cadonna > Center for Database and Information Systems (DIS) > Faculty of Computer Science > Free University of Bozen-Bolzano > > Piazza Domenicani 3 > 39100 Bozen/Bolzano > Italy > > web: http://www.unibz.it/inf
