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
On 10/07/2012 8:19 AM, 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-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
