HL7 ANY type

Thomas Beale thomas.beale at oceaninformatics.com
Mon Jul 9 18:49:29 EDT 2012


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





More information about the openEHR-clinical mailing list