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
