Hi,
I have a small question. I want to translate a HL7 ANY type to an OpenEHR-RM-type, and use the abstract type DataValue.
I wonder how this will be handled in AQL.
How do you query a type of which you don't know even the type of? Or is it possible to query the type of a DataValue in AQL?
I am sorry that I am not very familiar with the detailed aspects of AQL-specifications.
In fact, are there specifications published?
So, it became two small questions
Thanks for any help
Bert
Hi Bert,
Take a look at this as a reference: http://www.openehr.org/wiki/display/spec/Archetype+Query+Language+Description#ArchetypeQueryLanguageDescription-AQLidentifiedpaths
Regarding your question, I think the current specification for AQL does not discuss what would happen if an abstract type is used. In your case, you’re talking about using DataValue in the FROM section of query, but then you can only select parts or constraint features of the type DataValue, which would not really help you. imagine having something like:
select dv/…/ ->(what? dv has no attributes)
from DataValue dv <CONTAINS statement here, but CONTAINS what? dv has no attributes>
WHERE dv/…/… (some criteria for dv, but what? it has no attributes 
)
Unless my understanding of AQL fails me here, you can get all datavalue instances if you don’t introduce any criteria at WHERE clause and in SELECT, but that is all. In any implementation, that would be a big set of data, which you’d have to downcast in your own implementation and apply filters.. Would you like to discuss your use case in more detail?
People who know AQL better than me, please do not hesitate to educate me…
Regards
Seref
Op 09-07-2012 17:15, Seref Arikan schreef:
implementation, that would be a big set of data, which you'd have to downcast in your own implementation and apply filters.. Would you like to discuss your use case in more detail?
Hi Seref,
Thanks for your interest.
The use case is about, that we need to write a set of archetypes which is usable as datastorage for a HL7 VMR-model in a decision-system. In this model, there is an ObservationResult with type ANY to hold the observation-value.
The only query-able solution we can find is to specialize the archetype to common situations. We have, for example an ObservationResult related to pregnancy, in a specialized archetype.
Depending on the kind of DataValue, there are other attributes.
The customers/users, however are not happy with this. They wonder how it is be done in HL7, of they have the same problem. I don't know, does someone know?
What would be a good solution, it would be good also if AQL had a solution to query the type of a datavalue, and than it would be possible to query the value, depending on the type, there would be another attribute to query.
Someone has an answer/suggestion to this?
regards
Bert Verhees
Hi Bert,
I’m trying to get my head around your requirements. I can’t say I’ve clearly got it, but let me try to reply via inline comments.
Op 09-07-2012 17:15, Seref Arikan schreef:
implementation, that would be a big set of data, which you’d have to downcast in your own implementation and apply filters.. Would you like to discuss your use case in more detail?
Hi Seref,
Thanks for your interest.
The use case is about, that we need to write a set of archetypes which is usable as datastorage for a HL7 VMR-model in a decision-system. In this model, there is an ObservationResult with type ANY to hold the observation-value.
The only query-able solution we can find is to specialize the archetype to common situations. We have, for example an ObservationResult related to pregnancy, in a specialized archetype.
Depending on the kind of DataValue, there are other attributes.
This sounds reasonable. If we’re talking about the HL7 ANY type, is not that the highest type in the data types hierarchy? An abstract type with only nullflavor attribute, right? So when you say the observation value can be ANY, it means any data type, so your choice of DataValue may not be a bad match for the same thing. Tom and Ian may offer something better, but I’d probably give DataValue a try just like you’re doing.
The customers/users, however are not happy with this. They wonder how it is be done in HL7, of they have the same problem. I don’t know, does someone know?
Sorry, I’m not sure if I’m getting this. Why are they unhappy? Unless there is a trick in the HL7 type system for this, you’d have to do type checking on the observation value to find out its actual type. There are members of this list with serious HL7 experience, may they may like to comment about how to do this in HL7. Anyone? Do they have a problem with HL7, and are they asking you to solve it by implementing something in openEHR? If so, you seem to be on the right path. In short: what is the problem ?
What would be a good solution, it would be good also if AQL had a solution to query the type of a datavalue, and than it would be possible to query the value, depending on the type, there would be another attribute to query.
I would not call that a good solution. It feels like you’re pushing something that belongs to a higher level to a lower level, to AQL. Can you give a hypothetical syntax example for the feature you’re asking? How would write your query if you had the feature you’re asking for?
Someone has an answer/suggestion to this?
Well, unless I can see what is wrong with your approach, I’ll suggest that you go ahead with what you seem to be doing
Op 09-07-2012 17:15, Seref Arikan schreef:
implementation, that would be a big set of data, which you'd have to downcast in your own implementation and apply filters.. Would you like to discuss your use case in more detail?
Hi Seref,
Thanks for your interest.
The use case is about, that we need to write a set of archetypes which is usable as datastorage for a HL7 VMR-model in a decision-system. In this model, there is an ObservationResult with type ANY to hold the observation-value.
The only query-able solution we can find is to specialize the archetype to common situations. We have, for example an ObservationResult related to pregnancy, in a specialized archetype.
Depending on the kind of DataValue, there are other attributes.
Hi Bert,
well, the whole idea of archetypes is that you know what particular data configurations are actually being created, out of the billions of ones possible from the statically declared information model. With no archetypes, then you just have the information model, and you can query on that, but you have no idea what you are going to pick up because you don't know what your data are. But nothing technically prevents you from putting in paths that assume e.g. ObservationResult.value is a PQ, i.e. .../value/units or whatever it comes out to be.
The customers/users, however are not happy with this. They wonder how it is be done in HL7, of they have the same problem. I don't know, does someone know?
there's no problem here - it is how any information system works - if there are no archetypes, you just end up querying on the static information model and hope for the best.
What would be a good solution, it would be good also if AQL had a solution to query the type of a datavalue, and than it would be possible to query the value, depending on the type, there would be another attribute to query.
at the moment this would not generally be possible, because it would rely on the concrete persisted form of the objects including their data type (i.e. 'class name'). The openEHR RM doesn't mandate this, although someone might add it to there private persistence solution. If it were there e.g. if you added an attribute to LOCATABLE like rm_type: String and then query on that.
Why not just use archetypes and templates? This achieves the same result in a better way. Even if your archetypes are generic for attributes like the above one, obviously some particular data type was chosen at run time. You can include in your archetype all sensible alternatives for the attribute in question, each with its own at-code. Then when the data are stored, they will have the at-code of the actual archetype node used, i.e. the TS or PQ node or whatever. That means you can build an AQL query for exactly that data object.
- thomas
Thanks Thomas and Seref,
You both were really helpful. I think I have enough arguments to convince my customer to do the right thing.
I think the solution with more datavalues and according element-structures each with their own datavalue is a the best solution.
kind regards
Bert
HI Bert
Heath is away but he will share with you that we have been taking the same approach. LOINC codes or name values are the basis for our queries when there is no specific archetype. So we have the path to the values, but use the names of the elements for queries.
Cheers, Sam
don’t forget you can always use alternatives at the Element.value point in an archetype - it’s perfectly legitimate, e.g. ELEMENT matches { value matches { DV_COUNT matches {…} DV_CODED_TEXT matches {…} } } this means that the data has to match a DV_COUNT or a DV_CODED_TEXT, which greatly reduces the possible unknown instance space you query against. - thomas