Thomas Beale schreef op 17-2-2014 14:59: > > Bert, > > I think we can achieve more flexibility than the current RM without > too much change, and keeping the useful components that exist today. > > On 17/02/2014 09:28, Bert Verhees wrote: >> Bert Verhees schreef op 16-2-2014 16:57: >>> Or is it possible that a new way of structuring health-data can come >>> to life with no clear use for the semantic rich ENTRY-classes. >> For Example, the OpenEHR/13606 EHR is build around the COMPOSITION >> Paradigm. This is a concept, which means: according to the >> EN13606-definition: "The COMPOSITION represents the set of >> RECORD_COMPONENTS composed (authored) during one user?s >> clinical session or record documentation session, for committal >> within one EHR." >> >> I believe in OpenEHR this is similar, but I am too lazy to check. >> >> This is fine as long as one wants to stay inside this paradigm and >> one is willing to classify data to the semantic headers like >> EVALUATION or OBSERVATION, etc. >> But at the same time, this is also a kind of straitjacket. >> >> It prevents innovative thinking about data. >> Sometimes, for example it is not that clear if something is an >> EVALUATION or OBSERVATION and forcing someone to classify can lead to >> an unclear base of classification, and in severe cases even to >> unfindable data. > > Can you say how this could happen? If there is doubt, just choose the > one that seems to fit, and use it. I think the only question is: for a > given clinical content model, is there no RM option that fits at all? > Are there cases like this?
It is more the approach which is unnecessary limited by the semantic design, it can block a new approach, and it makes paths too much depending on the semantic pre-classification enforced by the RM. It could be possible to define afterwards if something is an Evaluation or an Observation. There are gray area's between the two, in cases of interpreted Observations, and that is no problem. The problem is only that now one has to decide at storage-time what it is, while it could also be afterwards on reading time. One could also change opinion. And now, there are four nouns to choose from, maybe a new approach wants three or five. It is not possible in this RM. This can block innovation. > >> --- >> Not that I am capable of inventing a new health-data-schema, but I >> can see that semantic constraining in the RM is harmful. >> >> An alternative way would be to build a new Schema of Health-Data. >> Maybe there are some clever people out there, which are smarter then >> the predefined semantics. >> Maybe the general opinion about the predefined semantics changes it, >> and the RM become subject of obsolescence. >> But this would only be possible if the RM offers liberty to do so. > > In the next release is there is a concrete Entry structure that is a > free tree, that should help. Exactly, that is what I wanted to say. Not some Generic_Entry in a dark edge of the RM for hesitating people, but a full grown, ENTRY with the status of every other Entry, to be there as a choice for alternative data-modeling. > > Note that if that gets used a lot, and different modelling groups need > to model timing, various context, and they have to do it themselves, > they will end up modelling things in a non-interoperable way, so that > software can't be build that knows how to read the data. This is the > danger. > >> >> To be innovative, we need freedom of thinking. > > With complete freedom comes complete chaos. E.g. the current world of > wiki & blog syntaxes - all a backward step compared to even HLTML 3, > all non-interoperable... now we can't even do online software > documentation that is shareable across tools. Of course, but there will never be freedom, there will always be data-modeling and constraints in thinking. The matter is now that the constraints are on RM-level (first level modeling), and they should be in data-modeling level. In the second level of data-modeling (as the concept two level modeling promises) > yep, this is what will appear in the next release of the openEHR RM - > ideally a 13606/openEHR merged RM. Thanks for letting me explain Bert
