Grahame, One of the theoretical difficulties of the debate that you are contributing so eloquently to is to separate methods proper to computing from methods defined by domain specificity. Object-oriented programming, modular design, abstract data types, etc. are fundamental principles whose existence does not follow from any particular domain features. They lead to better information modelling in terms of architecture, computational semantics and have been adopted as the best engineering methodology to create information processing systems. The abstractions that bridge the gap between computing and domain-driven modelling have to be able to represent in machine processable form the business objects we are dealing with. What you are doing in this case is less important than what you are doing it to. The marriage of the two strands does not deny their individuality but produces an offspring that blends their essential features in an organic way.
openEHR contains RECORD in its name as the basic abstraction. The RECORD is a container structure that has well defined computational semantics - data entry is structured in the form of compositions that may be of different type (instruction, observation, etc.) because of differences in computing requirements - data representation, etc. Thus we have a model of a record (document) management system which at its highest level is generic. However, its type system is geared towards the faithful representation of information in the health care domain with the goal of producing a shared longitudinal patient record. HL7 as the name attests is based on the messaging paradigm. The MESSAGE has been historically the modelling abstraction that defines HL7. Thus, we have to ask ourselves, which root abstraction fits better the twin criteria of clear and purposeful computational semantics and faithful representation of domain specifics. You said: > ok, we have real convergence here. > OpenEHR works exactly like HL7 - define a reference model > with all the needed semantics, and then refine things away > in constraint models (and use the refinements as a basis for > composition). So the principle is the same. (I have the feeling that you are thinking of HL 7 V4.0) Convergence is a really strong statement. I understand your motivation and your honest desire to overcome the gap between openEHR and HL7. However, one has to be equally honest in appraising the two approaches and their results. openEHR doesn't "work exactly like HL7". A brief look at the history of the two would show that while openEHR has always been based on sound software engineering and knowledge modelling principles, HL7's effort to a reference model to its messaging structures is not necessarily a product of organic development, hence th gap between version 2 and version 3. openEHR does define a reference model with all the needed computational semantics but leaves domain-specific knowledge modelling to the second level of its methodology - archetype modelling. Implementation efforts have clearly shown openEHR's ability to produce clean clean computational models that enhance domain-specific semantic interoperability first and foremost throught the strict enforcement of the separation of concerns between information modelling and knowledge representation. The two sides click together at run-time in a very efficient and effective way. This is not refining things away in constraint models. The fundamental difference is how one deals with modelling or how one uses abstraction. "Abstraction means to strip away the superficial or incidental aspects of a thing and to reveal its most important aspects, or essence, aka theory, hypotheses. Abstraction is important and can lead to deeper (beyond surface understanding ) of things. Abstraction can also go wrong. There are different ways to abstract. How do we test whether our abstractions (theories, hypotheses) are right or wrong?" (to quote a good blog: http://billkerr2.blogspot.com/2006/08/ascending-from-abstract-to-concrete.html). The key to using abstraction in theoretical modelling is to understand how one can "ascend from the abstract to the concrete." I don't think constraining and refining actually play such an important role in the design process. The same blog: "Marx talked of "ascending from the abstract to the concrete" which on the surface can seem rather absurd. How can a concrete view of reality be superior to a more abstract view? We all know that science takes us beyond the surface appearance of things and proposes deeper explanations that are not immediately apparent. And anyone who has studied child development knows that initially children view the world in a "concrete" way and as they become able to think better they become capable of thinking more abstractly. So isn't abstract thinking more advanced than concrete thinking? The difficulty arises from confusing the Marxist idea of "the concrete" with the idea that what is concrete is that which is easily and immediately perceived via the sense organs - ie the surface appearance of things. (note: the whole idea of anything being "immediately perceived" is in any case incorrect. Perception always involves some cognitive processing ). However what Marx meant by "concrete" was not what is meant by the pedagogical distinction between concrete and abstract (or formal) thinking. Marx's use of the word "concrete" has to do with the notion of truth and is not related to the idea of concrete thinking as child-like and primitive. To ascend from the abstract to the concrete means to move from the initial ability to abstract away from surface appearance (via everyday and relatively easy generalisations and simple concepts) toward a richer and more accurate view of concrete reality. This does involve abstraction - but it is abstraction that is on its way to a richer and more concrete (truthful) world view." You don not find the richer and more truthful world view through constraining and refining. You have two processes at work: the first one is maintaining valid and verifiable data structures that exist within the type system of your information model; the second one deals with concrete instances of data and information from the clinical world that live in your software system, their machine processable nature is defined by computer semantics and platform specificity but their meaning is not. The concrete clinical notions modelled via archetypes are thus something more than just a constrained pattern. These produce concrete instances, objects much richer in content than the abstract model whose elements they represent. The trick is to accomplish this ascent seamlessly within your defined universe on the basis of a stable single view of that universe. Your knowledge model represents the domain-specific semantics your are dealing with and it will exist with or without an underlying computational system. But machine processing requires that we have a working system even when our knowledge acquisition process is ongoing. To sum up - information models are based on abstractions and data types chosen because of their computational semantics and suitability to faithfully represent instances of domain-specific business objects. The latter derive their meaning from the theoretical (clinical) body of knowledge and the only information processing constraint is that they be in a machine computable form, that is, they do not break information model and the sharing of data between system. Archetypes represent concrete reality as machine processable entities that co-exist in the same knowledge universe. This universe is open to future study and representation. What is important in openEHR's view of the world is to abide by the open/closed principle which means that our models should be closed in a sense that they can work today while leaving open the system boundaries for future extension (sic!). > > We can generate [class models|schemas|wire formats] from > constraint patterns. Doing so has benefits and costs. The > same benefits and costs in either HL7 or OpenEHR. And one > of the clear costs relates to persistence. I think we need > to search for a better way, but that's not going to happen > in the short term. Persistence is orthogonal to design and modelling. Persistence closure requires that all object references be stored and then reproduced when necessary (it doesn't need to know about actual object creation). It also involves efficient query mechanisms but again, we have two sides of the same story - generating class models, schemas, wire formats is a case of clean computational semantics while creating, storing and quering of knowledge structures (archetypes) has to do with domain-specific knowledge. I cannot comment on the costs of persistence but recent trends in database theory point in the direction of knowledge-aware persistence mechanisms. > But the OpenEHR & HL7 reference models are quite different. > In most parts, the HL7 reference model is more abstract > (Which is way Act gets 22 attributes). So harmonising between > the reference models is going to require actual change rather > than adroitly altering perspectives, as with data types and > the constraint model things. I don't think that one can discuss whose model is more abstract (or bigger). What interests me is whether the two models have the right abstractions for the task, and whether principles of information and knowledge modelling have been put to good use. Actual change should contribute to the goal of greater expressiveness and focused coverage rather than to the elusive goal of harmonisation. > This will be hard, and painful. And it must involve compromise, > so this is when we find out who really values collaboration. Blood, sweat and tears? In the name of what? What do you mean by compromise? What is the nature of compromise in scientific research? This is a term that belongs in areas such as politics and conflict resolution. In research, the middle ground, as Goethe would say, is where conflict begins (my apologies for the imprecise quote). Who really values collaboration? Again, strong words, Grahame. What is the nature, program and goals of such collaboration? Is it the creation of an open Electronic Health Record based on computational and domain-specific semantic interoperability? What is the mechanism of this collaboration? I'd be interested to see the specific research program and see how emerging joint efforts lead to uncompromising collaboration in the name of a clearly defined final goal. > And we don't want to take away the real benefits that OpenEHR > has in the process (same for HL7) I agree, Ogi Pishev
