HL7 ANY type
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.
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
More information about the openEHR-clinical