Grahame Grieve wrote: > Hi Tom > > >> The main difference architecturally is that there in openEHR there is a >> reference model from which software and systems can be built. >> > > This is not a difference; it's true of HL7 as well > I think people would have a hard time finding it - where is the reference model from which you can build software? It's not the RIM as we are told time and time again (I can pull a dozen quotes from all the core RIM designers to say that the RIM is not a basis for software, only generating other schemas - this has been practically religion for 10 years)... you could call the sum total of all the HMDs a "reference model" I guess, since they are what software is based on, but that's stretching the meaning of the term...anyway, it's a pretty clear difference for all practical purposes. > >> In HL7, the data are instances of schemas that are >> progressively refined from the RIM. >> > > well, it doesn't have to be; and also, you could do this with archetypes > and/or templates, and it would have some use too. > I'm just saying how things work now, so that new people have some hope of understanding. I doubt if it would have any use with archetypes / templates though - the subtractive logic based on relational projections just isn't a part of normal object modelling or openEHR. > >> In recent discussions with the >> designers, they claim that the theory of DIMs, RMIMs etc is based on >> "relational projections" on the RIM (i.e. that's the basis of attribute >> "removal"). >> > > well, I can't speak for "the designers" (I'm spending some time with him > today on this subject ;-), but archetypes and HL7 models are the same thing. > I can interconvert between them. The only issues are syntactical differences > in things that are allowed in each language, and they are minor. Obvious > conclusion: they are the same thing. > That's a somewhat misleading statement. An archetype isn't a new model; it's a statement about putting together pieces from an existing model. An RMIM is a new model with respect to the model from which it was derived - different classes, different attributes. That's the whole point of the HL7 refinement method - to iteratively derive new schemas from the RIM...you can't pick up an RMIM and say what configuration of classes from another model you have, because you don't have classes from another model, you have _modified_ classes from another model. I know that some RIM people will then say that the classes aren't really modified, the missing attributes are "projected out", which means the new classes are indeed new classes - each one specifying a new projection on a class in the preceding model. Which brings us to the question of the quality of the original model (the RIM), as well as the details of the refinement method as a way of specifying content models.
Some archetypes and RMIMs are trying to say the same thing however. Is reliable machine conversion possible? The key point is that while conversion between the formalisms of some part of an archetype and an RMIM and vice versa may be possible, conversion between actual real archetypes and real RMIMs is not the same thing, due to the reference models involved. Conversions that might be considered: a) existing openEHR or CEN archetypes -> RMIM "language" - based on the RIM? b) existing RMIMs -> archetypes based on the RIM c) existing RMIMs -> archetypes based on openEHR a) might be possible, but seems hard, because the RIM lacks numerous primitives present in the openEHR reference model; if it was achieved, it would allow openEHR content to be communicated in an HL7v3 message (although why incur all the pain of transformation at both ends, when the information can just be sent in the normal way is beyond me - sending it as an opaque payload would be easier and safer); b) may well be doable, and I suspect is the transformation you have most likely achieved already - this would allow archetyping tools to be used in HL7, but still wouldn't provide a way for openEHR archetypes to be used in HL7, due to the difference reference models; c) I cannot see being possible because of the differences in reference models and also another problem: it is hard to tell with RMIMs what was intended and what "had to be done that way" due to the limited language available in the RIM. Actually reverse-engineering the true intention of the modellers from an RMIM in general will be hard, due to this effect, and it should not be under-estimated. So c) is only likely to be doable my manual means, but it certainly should be considered, because there is a goldmine of domain thinking locked up in the RMIMs which needs to be shared by systems and technologies outside of HL7v3 messages. One of the things newcomers to this field have to do is have a very hard look at the reference models involved, how they enable semantically rich systems and how they provide business value; then they need to understand the methodologies involved in actually building software, and what the costs and benefits are. - thomas beale
