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 Bert 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 > >
