HL7 ANY type

Bert Verhees bert.verhees at rosa.nl
Tue Jul 10 02:51:29 EDT 2012

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

On 10-07-12 00:49, Thomas Beale wrote:
> On 09/07/2012 22:41, Bert Verhees wrote:
>> 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
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org 

More information about the openEHR-clinical mailing list