Hi Erik > 1. Will the XML schema get updated to make sure patient data instances > carry along the archetype/template inheritance in a good way? [HKF: ] I have spoken with Tom on this topic considerable, we are looking at extending the ARCHETYPED class to support a list of archetype_ids (similar to HL7 CDA class having multiple template_ids) to support matching on any of these in queries. We think this is the least impact change while supporting queries without the need for an external archetype ontology service.
> 2. Should AQL be modified to include a convenient way of specifying if > we are asking for data only entered using a specific archetype or if > we are looking for data entered using that archetype any of its > specialisations? (Previously wildcards might have worked depending on > interpretation/implementation of AQL documentation, now with the 1.5 > change they definitely won't.) What should be the default behaviour if > just writing an archetype name in part of the query? [HKF: ] Yes, RegEx expression will not be useful any more. > Quoting from the 01 Feb 2010 version of "Knowledge Artefact > Identification" Section 5.3.3: > ..."given an archetype X used to create data, the following archetypes > could be used for querying: > . X, i.e. exact same version, revision & commit; > . any previous revision of X; > . any of the specialisation parents of X; > . any previous revision of any of the specialisation parents of X." > > Does the "could be used" wording here mean that the default behaviour > of an AQL response should be to retrieve data matching all these > cases? [HKF: ] From my discussions with the clinicians, this seems what they want. When we designed AQL to use RegEx based on the structured archetype IDs, it seemed technically reasonable that we wanted to query a generic archetype without its specialisations so we made it explicit to request a generic archetype and its specialisations. This will need to be considered in the next iteration of query engines. We probably need some implementation guidance on this (along with many other topics). > 3. Will the semantics and syntax of the path strings used in PATHABLE > objects be affected? Where is that path syntax actually defined, is > chapter 11 of the Archetype Overview the authoritative source? Has it > ever been possible to find data from specialisations using calls to > methods of PATHABLE? Should it be? [HKF: ] I would not expect paths to have the same subsumption rules as queries, I would expect paths to be specific to a data instance. Heath
