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? > --- > 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. 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. > > I gave an example on this list a few weeks ago. > I explain it short, it could be an example of possible liberty of > another way of approaching health-care data in a semantic poorly > defined RM. > > For example, just an example, not a serious solution!!! > > An archetyped health-data schema could have a structure which makes > paths predictable and consistent, and easy to query, and even fast > indexes on data would be possible. > For this we would need a generic ENTRY. It exist in OpenEHR, but it > has a low status: "If you don 't know where to put something, put it > there, and else use the semantic ENTRIES." > > I would prefer more status, or better, giving more status to the > ENTRY-class by not making it abstract. And then making the ENTRY > preferable above the semantic entry-classes. > Then this would become possible, or even obvious or logical. yep, this is what will appear in the next release of the openEHR RM - ideally a 13606/openEHR merged RM. - thomas
