Hi Tim & Erik, Actually there are two means of querying data from an EHR, one is certainly using EHR_EXTRACTs where the extract contains complete versioned COMPOSITIONs. This is more intended to be used to exchange content between EHR systems.
The other is a more interactive mode where an application associated with a particular EHR system is making service calls to the system requesting data at different levels in the RM. AQL allows you to retrieve content at any level of the RM, a COMPOSITION, ENTRY, ELEMENT, DATA_VALUE or even a primitive type such as the QUANTITY.magnitude double. Therefore, there does need to be a container for these collection of objects. We have implemented a RESULT_SET that contains a list of RESULT_ROWs which contains a list items of type ANY. The RESULT_SET also provides a list of RESULT_COLUMNs that provides details of the column name and path. I think this kind of class is likely to be specified as part of the service model. Heath > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Tim Cook > Sent: Tuesday, 30 September 2008 9:31 PM > To: erisu at imt.liu.se; For openEHR technical discussions > Subject: Re: AQL-parser in Java? + AQL response format (using the AS operator) > > Hi Eric, > > I suggest that you read the Extract Information Model document. > Though it still needs some vetting, this should answer many of your > questions. > > Regards, > Tim > > > > > On Tue, 2008-09-30 at 11:04 +0200, Erik Sundvall wrote: > > Hi! > > > > 1. Has anybody planned, or started, to create an AQL-parser in Java? > > > > Maybe the basics from AQL to parse tree could be common for several > > different persistence implementations and then the rest of the > > implementation will be different for different persistence mechanisms. > > > > Our first interest will be in transforming AQL queries to queries > > against an XML-database containing versioned Compositions. (It's for > > an educational system where performance isn't crucial.) > > > > 2. Are there any suggestions for standardised response formats? It > > would be interesting if we could query each others' implementations > > (Python and various Java based ones) and interpret the response :-) > > > > When returning entire openEHR subtrees (an entire Composition or Entry > > for example) I guess the current XML-format could be used to start > > with. The response is likely to often be a list of such subtrees and > > the format of that list Would need to be standardised. > > > > Another case is when using the AS operator, how do we in a > > standardised way identify the named parts. > > > > Best regards, > > Erik Sundvall > > erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- > Timothy Cook, MSc > Health Informatics Research & Development Services > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > Skype ID == timothy.cook > ************************************************************** > *You may get my Public GPG key from popular keyservers or * > *from this link http://timothywayne.cook.googlepages.com/home* > ************************************************************** > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
