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: * 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. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: cadonna.vcf Type: text/x-vcard Size: 452 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080620/30738602/attachment.vcf>
