Hi Gerard! This will be an interesting process...
I think you will need to clarify several of your technical/modeling statements and motivations during the process, I find several of them a bit hard to understand. Gerard wrote: > We need to reduce the number of degrees of freedom producing archetypes. If you in the RM predefine ways to model certain things (e.g. timing in observations by introducing an OBSERVATION class) then you are in practice _reducing_ the degrees of freedom compared to leaving it completely open for free form modeling using clusters in an unspecific generic ENTRY. Remember that an unrestricted cluster has unlimited degrees of freedom. Gerard wrote: > We need to be able to use specialisations of the Entry class. > My thinking is that these health specific specialisations ( Observation, > Evaluation, Instruction, Action, etc.) must not play a role in the RM. > > We are working on an addition to the 13606 standard that defines how > semantic interoperability artefacts are structured, used in other semantic > artefacts, how standardised modeling patterns are used, etc. > In this scheme all these things define a standard for the semantic layer on > top of the present technical 13606 layer. > > I foresee a strict separation between the technical 13606 standard (as we > know it) and a semantic artefact layer (that we will need to wok on) > The technical layer is very generic, healthcare a-specific. > The Semantic artefact layer will have some health specific items > incorporated: e.g. Observation, etc. but even then contain many health > a-specific constructs that can be used outside of healthcare. > This thinking will have consequences for the present 13606 parts 1, 2 and 3. I assume "healthcare a-specific" means something like "more general and not specific to healthcare", is that a correct interpretation of your words? If so, why do you want to turn the 13606/openEHR into something "healthcare a-specific"? Wouldn't that be an enormous deviation from the current 13606 thinking and purpose? Was not 13606 intended exactly for healthcare? If you want a completely generic RM with the possibility of an infinite number of meta-layers on top then something like RDF (as RM) with OWL (as meta) on top seems to be what you are looking for. The RDF+OWL approach definitely has both good use-cases and good implementations but it is a very different approach than having a healthcare specific 13606/openEHR RM in the bottom layer. I think the approaches can co-exist perfectly and sometimes meet and data/models partly be translated between them for specific purposes. But if you try to completely morph one approach into the other you'll likely run into trouble. And what would a "healthcare a-specific" 13606 RM bring to the "healthcare a-specific" scene that is not already there in one form or another? What is the purpose of going "healthcare a-specific"? The base classes of the HL7 v3 RIM (ACT etc) are sometimes said to be "healthcare a-specific" and reusable in other contexts. But have they really been extensively adopted outside healthcare? Why would 13606 want to go there? Can't we leave that exploration to HL7? Another basic thing to explain is why things would get better or easier by introducing even more (meta?) layers of modeling. I think the levels of openEHR are many already, but they at least have been tested in real systems and real modeling work and have somewhat clear motivations for existing: 1. RM (for real software-implementable recurring stuff that you can optimize storage and query for in order to get fast usable EHR systems) 2. Archetypes (for finding/defining "maximal" datasets for closely related documentation needs, this provides shared queryable search paths) 3. Templates (for aggregating pieces and narrowing scope again to fit use cases) (Also add management of the interaction with terminology systems to all of the above before considering adding layers.) Erik wrote: >> A great thing would be to actually have at least two independent >> _implementations_ of change suggestions (both AM and RM) after initial >> discussions but before any revisions to the standard are made. That is >> how some other SDOs work with technical artefacts and it could avoid >> some of the previous suboptimal approaches. Gerard wrote: > So you agree with my NO. What NO? Please clarify. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
