William, Not to continue on the main debate - but with respect to your statement:
"I am still of the opinion that the semantic content of this R-MIM is 100% the same as the same content in an archetype. " It might be the case. But it is a problem like trying to express the same thoughts in Malay language and in Russian. In the former there are no tenses, and you have to add words indicating time, like 'yesterday' to do it. Russian is a richer language, so expressing sophisticated concepts in Russian a) takes less words and b) is likely to more closely express subtle concepts, tone of expression etc. In our world, we have to be able to machine translate models to say they are the same, or reuse one expression in the other world. If we can't do that, it is of only academic interest to say they are 'the same'. And the difficulty of doing machine translation on natural languages shows us how hard this is. Even across European languages, Google translate and other such tools are quite weak. Model translation as practised in IT does work somewhat in some circumstances - but is fairly unreliable (e.g. UML tool round-tripping). What enables or hinders such translation is the closeness or otherwise of the underlying grammatical structures; in our world, this is the reference models. - thomas On 25/11/2010 22:13, Williamtfgoossen at cs.com wrote: > > Just an example of downstream modeling designs in HL7 to > counterbalance Thomas erreonous comments on HL7 modeling. > > 1. The path to get to implementable HL7 v3 XML is quite clear: > we have the RIM as building blocks offering structure, attributes, and > behaviour. Pure UML modeling. > > 2. From the LEGO bricks using constraining, we create LEGO guidelines > (similar to the booklets that help in a step by step picture to put > the right bricks together). This is the Domain message inf. model. > > Each of these D-MIM is taking into account a multitude of use cases > identified and defined by clinicians, or from projects with clinicians. > > 3. Following the guideline booklet, actual messages are built, the R-MIMs > > 4. The object oriented models in R-MIM are serialised into XML. > > OK, that is the basic pattern. I have used this to create the about > 100 R-MIM examples covering a lot of clinical content on the level > that in the 13606 world would be an entry. I am still of the opinion > that the semantic content of this R-MIM is 100% the same as the same > content in an archetype. > > Well, I came to HL7 int with this and got 2 very important comments > from experts in different committees: > 1. That is an excellent example of representing clinical content in > HL7 v3 specification, it does follow the steps and rules 1-4 above. So > the modeling did fit. > 2. If we continue to work this way and downstream have to make R-MIMs > and serialize them we face the combinatorial explosion. If you have > 3000 entry level or data element / data element clusters and 1000 > assessment scales and want to vary that in the messages: well we face > 3000 x 1000 x 5? variations. That is not sustainable. > > Hence we abandonned to create fully specified R-MIMs for each clinical > artifact and changed the route to what now is DCM. DCM allow still at > conceptual level to express what clinicians want and need, but > downstream only deliver XML output with structure and coding etc in > such a format that it can be inserted in one and the same base > message. Hence the combinatorial explosion is 1 for instance for the > care record which holds the clinical statement pattern allowing such > serialised DCM content to be included. > > Hence, the downstream implementation in HL7 guided in this example the > modeling approach. > * > * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101126/e3d489d0/attachment.html>
