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. --- 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. To be innovative, we need freedom of thinking. 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. ENTRY[at0001] CLUSTER[at0001.1] DateTime[at0001.1.1] Code[at0001.1.2] Value[at0001.1.3] The code, which is on a consistent, predictable path indicates what is written here, no need to pre-classify it. The datetime, also on a predictable path allows fast querying on date-time. Both even without knowing the (slotted) archetype. But, remember, this is only an example, I am sure there are better ways to structure health-care-data when a matured liberal RM becomes a fact. Bert
